欢迎使用CSDN-markdown编辑器

light lock（轻量锁）

1. 保护内存结构
2. 轻量锁不可重入，因为他不检测持有人，单进程重复加锁会导致死锁
3. 没有死锁检测机制，必须顺序加锁
4. 不允许直接锁升级，必须先放锁后加锁，这有两个原因，1是轻量锁不可重入，2是锁升级可能导致死锁，而轻量锁没有死锁检测机制
5. 加常规锁之前必须释放所有轻量锁

regular lock（常规锁）

常规锁用于保护逻辑上的一致性，以来共享内存中的常规锁锁表实现

放锁规则

1. 主事务commit，释放出session锁外的所有锁；
2. 主事务abort，释放所有锁，包括session锁；
3. 子事务commit（即release savepoint），不释放任何锁；
4. 子事务abort（即rollback to savepoint），释放子事务运行过程中申请的所有锁；

行锁

行锁在实际运行时异化为事务锁，举例说明其流程：
1. Tx1, 启动的时候对自己的事务ID加锁，操作行时将事务id标记在行头；
1. Tx2, 发现冲突，对行加tuple锁，并锁对方的事务id，等待；
1. Tx3，发送冲突，对行加tuple锁，等待

schema

有人操作schema下的表时，不允许删除schema。

drop schema cascade时不对schema加锁，但是会顺序删除schema下的所有表，如果有冲突，会阻塞在表上。即使不加cascade，也会阻塞在表上，而不是报错。

role

role不加锁，直接查询pg_shdepend，如果有依赖这个role的表，那么直接报错。

function

function无锁，即使有事务使用过这个function，依然可以drop成功，此时使用过这个function的事务依然可以调用这个function，但是事务结束后，就不能调用了，如果事务没有执行过function，那么不管事务什么隔离级别，都不可以使用这个function。

view

PG不支持可更新视图或物化视图，虽然可以通过创建rule达到类似效果，但仍然操作的是table，因此view的冲突场景只有select和drop，此时当做table处理，按照table的方式加锁。

LockBufferForCleanup

不仅需要lockbuffer，还需要等待buffer header上的pin为1,。如果buffer上的pin不为1，那么设置buffer header上的wait backend pid为进程本身的pid，然后阻塞自身。当调用unpin buffer时，如果refcount为1，那么检测是否有需要唤醒的进程，如果有那么唤醒对应进程。

这个流程需要保证进程对buffer独占，它的实现方式和常见的锁处理方式不同。