postgresql共享行锁实现原理研究
postgresql共享行锁实现原理研究
背景
锁是数据库很重要的机制,postgresql支持表锁,行锁,了解postgresql行锁机制有助于我们在应用中分析和解决行锁的问题。
锁模式
当前postgresql支持4种行锁模式: FOR KEY SHARE, FOR SHARE, FOR NO KEY UPDATE, FOR
UPDATE,我们常见的delete场景获取的均为FOR UPDATE锁,而update场景会获取FOR NO KEY
UPDATE或者FOR UPDATE,要看有没有唯一索引了。 下面表格记录了4种锁模式的兼容情况。
![postgresql共享行锁实现原理研究 postgresql共享行锁实现原理研究](/default/index/img?u=aHR0cHM6Ly9waWFuc2hlbi5jb20vaW1hZ2VzLzU5Mi81ZTJhOTZhYzBkM2M1OWVkZGMzZGE0ZTNkOGY3MzhlMC5wbmc=)
加锁流程
-
首先加事务Exclusive锁
行锁等到事务提交才会释放,其他事物如果等待这个行锁,必须等待这个事务锁释放。以Update为例,首先分配一个事务xid,这个时候会对事务xid加锁,AssignTransactionId->AssignTransactionId->LockAcquire,这个锁是个内存锁。 -
判断是否需要锁等待
如果一个tuple被修改或者删除后,会记录xmax和t_infomask,ExecUpdate->heap_update->HeapTupleSatisfiesUpdate会返回tuple状态,只有当前Tuple上的Xmax或者MultiXactId还在活跃事务列表,会进行锁等待
-
加tuple锁
tuple锁可以保证多个修改事务加锁的顺序问题,原则是先来先拿锁,修改完tuple后,tuple锁会立即释放,而事务锁不会释放。假设有3个事务,A、B、C依次对同一行修改,均未提交,这个时候,A处于idle
in
transaction状态,B持有tuple锁但是等待A的事务锁,C等待B持有的tupe锁。调用函数为ExecUpdate->heap_update->heap_acquire_tuplock -
等待Xmax事务Share锁
等待事务锁之前,需要释放page锁,这样不会阻塞当前page上其他tuple的访问。调用函数ExecUpdate->heap_update->XactLockTableWait,其他事务commit或者abort后,等待事务会被唤醒,这个时候需要重新检查tuple上的xmax是否发生变化,如果发生变化,需要等待新的xmax事务提交。
MultiXact
对于FOR UPDATE和FOR NO KEY
UPDATE锁,可以方便通过Tuple上的xmax判断谁持有锁,而对于FOR SHARE和FOR KEY
SHARE,一个Tuple上面可能会被多个事务加锁,Tuple上动态维护这些事务代价很高,为了便于维护这些事务状态,postgresql引入了MultiXact机制,把多事务记录到独立buffer和文件中,如图所示。当触发多事务机制时,会生成一个新的MultiXactId,把当前Tuple对应的所有锁成员放在MultiXactMemberPage中,并把新的MultiXactId保存在xmax中。
总结
postgresql行锁相对于Oracle和MySQL的实现还是有区别的,Oracle记录在ITL中,但是不支持select
for
share,MySQL记录在bitmap中,但是当更新特别多的时候,产生大量的行锁,bitmap会占用大量内存。