2021@SDUSC

目录

概述

 PostgreSQL 的并发控制

PostgreSQL中定义的两种隔离级别

 PostgreSQL 中的三种锁

 SpinLock

 LWLock

 LWLock的数据结构

总结

概述

上周结束了postgreSQL的事务处理源码分析，这个周分析一下PostgreSQL并发控制的实现机制。

 PostgreSQL 的并发控制

PostgreSQL中存在多个会话试图同时访问同一数据的情况，并发控制的目标就是保证所有会话
高效地访问，同时维护数据完整性。
PostgreSQL为开发者提供了丰富的对数据并发访问进行管理的工具。在内部，PostgreSQL 利用
多版本并发控制( MVCC)来维护数据的一致性。这就意味着当检索数据时，每个事务看到的都只
是一段时间之前(不同隔离级别下所看到的事务开始之前)的数据快照(一个数据库版本)。这样，如果对每个数据库会话进行事务隔离，就可以避免一个事务看到其他并发事务的更新而导致不一致的数据。经过分析，PostgreSQL里也有表和行级别的锁定机制，因为MVCC并不能解决所有的并发控制情况，所以还需要使用传统数据库中的锁机制来保证事务的并发。另外，PostgreSQL 还提供了一个锁机制叫做会话锁机制,利用它可以扩大锁的使用范围，即一次对某个对象加锁可以保证对于多个事务都有效。
经过查阅资料，SQL标准考虑了三个必须在并行的事务之间避免的现象:
1)脏读(Dinty Reads): 一个事务读取了另一个未提交的并行事务写的数据。
2)不可重复读( Non- repeatable Reads): 一个事务重新读取前面读取过的数据，发现该数据已
经被另一个已提交的事务修改过。
3)幻读(Phantom Read): 一个事务重新执行一个查询，返回一套符合查询条件的数据，发现
这些数据因为其他最近提交的事务而发生了改变。
为了避免出现这三种现象，SQL标准定义了4个事务隔离级别

隔离级别	脏读	不可重复读	幻读
读未提交	可能	可能	可能
读已提交	不可能	可能	可能

隔离级别	脏读	不可重复读	幻读
可重复读	不可能	不可能	可能
可串行化	不可能	不可能	不可能

在PostgreSQL里，可以请求四种可能的事务隔离级别中的任意一种。但是在内部，实际上只有
两种独立的隔离级别，分别对应读已提交和可串行化，可能实现MVCC的缘故。如果选择了读未
提交的级别，实际上用的是读已提交;若选择可重复读的级别，实际上用的是可串行化。所以实际
的隔离级别可能比选择的更严格。这是SQL标准允许的:四种隔离级别只定义了哪种现象不能发
生，但是没有定义哪种现象一定发生。

PostgreSQL中定义的两种隔离级别

●读已提交(Read Committed): 这是PostgreSQL里的缺省隔离级别。当一个事务运行在这个
隔离级别时，一个SELECt查询只能看到查询开始之前提交的数据而永远无法看到未提交
的数据或者是在查询执行时其他并行的事务提交所做的改变。如果两个事务在对同一元组
进行更新，第二个更新事务将等待第一个更新事务提交或者回滚。如果第- - 个更新回滚,
那么它的作用将被忽略，而第二个更新者将继续更新最初发现的元组。如果第一个更新者
提交，系统将重新计算查询搜索条件( WHERe子句)，如果元组符合条件,则第二个更新
继续其操作，从该元组的已更新版本开始。
●可串行化( Serializable): 它提供最严格的事务隔离。这个级别模拟串行的事务执行,就
好像事务一个接着一个地串行( 而不是并行地)执行。如果两个事务在对同一个元组进
行更新，可串行化的事务将等待第-一个 正在更新的事务提交或者回滚。如果第一个更新
者回滚，那么它的影响将被忽略，这个可串行化的事务就可以在该元组上完成其更新操
作。但是如果第一个更新者提交了，那么可串行化事务将回滚，从头开始重新进行整个
事务。
在PostgreSQL系统中，事务的隔离级别所涉及的最小实体是元组，所以对元组的操作( 例如读
取、插人、更新、删除)需要实施访问控制，它们是通过锁操作以及MVCC相关的操作来实现的，
在本章后面的内容中将详细介绍。下面举例说明在PostgreSQL两种不同的隔离级别下事务的执行过程。假设有两个事务T1和T2并行执行，它们的执行情况如下。

事务T1	说明	事务T2
BEGIN	事务开始执行时，事务管理器为新事物分配XID；在共享内存中分配空间存放该事务结构；将新事物的XID返回给正在调用的进程。	BEGIN
UPDATA C
SET teacher='J.D.Ulman'WHERe CNO='30001'	自动给cno为”30001“的记录加排它锁（ExclusiveLock）
SELECT*FROM C	事务提交时，事务管理器调用日志管理器，将日志中的状态改成提交，并将日志刷新到磁盘，同时调用所管理用于释放该事务所持有的所有锁	SELECt*FROM C
END
		UPDATe C
		SET cname='Database'WHERe CNO='30001'

如果当前的隔离级别是读已提交，则事务T2中的“SELECT * FROM C”语句执行时看不到T1
对数据库的修改，但“UPDATe C”语句可以看到。所以，在执行“UPDATE C”时，从已更新的
数据版本开始。
如果当前的隔离级别是可串行化，则事务T2中的“SELECT★FROM C”语句执行时看不到T1
对数据库的修改，“UPDATE C”语句也看不到T1对数据库的修改。那么可串行化事务T2将回滚,
从头开始重新进行整个事务。
 

 PostgreSQL 中的三种锁

PostgreSQL实现并发控制的基本方法是使用锁来控制临界区互斥访问。后台进程对磁盘文件进
行访问操作时，首先要获取锁。如果成功获得目标锁，则进入临界区执行磁盘读写访问，访问完成
后退出临界区并释放锁;否则，进程睡眠直到被别的后台进程唤醒后重试。
PostgreSQL中定义了三种锁，分别是SpinLock、LWLock 和RegularLock。

 SpinLock
 

SpinLock是最底层的锁，使用互斥信号量实现，与操作系统和硬件环境联系紧密。SpinLock 分
为与机器相关的实现方法(定义在s. Jlock.c中)和与机器不相关的实现方法(定义在Spin.c中)。.
SpinLock的特点是:封锁时间很短，没有等待队列和死锁检测机制，事务结束时不能自动释放
Spinlock。
作为一种最底层的锁，一般不直接使用SpinLock,而是利用它来实现其他锁(LWLock)。毫无疑问，依赖于硬件的SpinLock机制肯定比不依赖于硬件的SpinLock 机制速度快。因为不依赖于硬件的SpinLock机制需要使用PG信号量来仿真SpinLock。如果机器拥有TAS (test-and-set) 指令集，那么PostgreSQL 会使用s_ lock. h和s_ lock. c中定义的SpinLock实现机制。如果机器没有TAS指令集，那么不依赖于硬件的SpinLock的实现定义在Spin. c中，需要用到PostgreSQL定义的信号量PGSemaphore。

 LWLock

LWLock (轻量级锁)主要提供对共享存储器的数据结构的互斥访问。LWLock 有两种锁模式,一种为排他模式，另一种为共享模式。轻量级锁不提供死锁检测，但轻量级锁管理器在elog恢复期间被自动释放，所以持有轻量级锁的期间调用elog 发出错误消息不会出现轻量级锁未释放的问题。
LWLock利用SpinLock实现，当没有锁的竞争时可以很快获得或释放LWLock。当一个进程阻塞在一个轻量级锁上时，相当于它阻塞在一个信号量上,所以不会消耗CPU时间，等待的进程将会以先来后到的顺序被授予锁。简单来说，LWLock的特点是:有等待队列、无死锁检测、能自动释放锁。

 LWLock的数据结构

LWLock主要提供对共享存储器的数据结构的互斥访问。
可以看到，LWLock 的数据结构中定义了一个互斥量mutex。使用SpinLock对此互斥量加/解锁即可实现对一个LWLock的互斥访问。
系统用一个全局数组LWLockAray管理所有的LWLock。在PostgreSQL中.有29个LWLock被系统默认使用(如OidGenLock、W ALInsertLock、CheckpointLock 等，可参考LWLockId)。用户还可以使用自定义LWLock来实现分段锁表。系统初始化LWLockAray时，为LWLockArray多分配了2个整型的空间,一个用来存储已分配的LWLock数量，另一个用来记录可分配的LWLock总数。

typedef struct LwLock
{
slock_ t mutex;//保护LWLock和进程队列
bool releaseOK :
char exclusive;//0或1,持有排他LWLock锁的后端数目
int shared; //持有共享LWLock锁的后端数目(0. . MaxBackends)
PROC *head;//进程等待队列的头
PROC *tail; //进程等待队列的尾，当头为空时,尾不确定
} LwLock;

总结

这周并行控制实现机制开了个头，并分析了两种锁，下周计划分析完三种锁，和锁的操作。欢迎批评指正。