锁机制在 PostgreSQL 里非常重要 ,对于DBA(特别是那些涉及到高并发代码的程序员),需要对锁非常熟悉。特别是某些问题,锁需要被重点关注与检查。大部分情况,这些问题跟死锁或者数据不一致有关系,基本上都是由于对 Postgres 的锁机制不太了解导致的。
Postgres 有 3 种锁机制:表级锁,行级锁和建议性锁。表级和行级的锁可以是显式的也可以是隐式的。建议性锁一般是显式的。显式的锁由显式的用户请求(通过特殊的查询)获取,隐式的锁是通过标准的 SQL 命令来获取。
除了表级和行级的锁,还有页级共享/排除锁,用于控制对共享缓存池里表页的访问。在一行数据被读取或者更新后,这些锁会立即被释放。应用程序开发者通常不需要关注页级的锁。
大多数的表级锁是由内置的 SQL 命令获得的,但也可以通过锁命令来明确获取。可使用的表级锁包括:
重要的是要知道,所有这些锁都是表级锁,即使它们名称里有行(ROW)字。
每个锁模式的最重要的信息是与彼此冲突的模式列表。在同一时间同一个表中,2 个事务不能同时保持相冲突的锁模式。事务永远不会与自身发生冲突。 非冲突的锁可以支持多事务并发。同样重要的是要知道有的模式和自身冲突。一些锁模式在获得后会持续到事务结束。但如果锁是在建立一个保存点后获得,保存点回滚后锁会被立刻释放。
下面的表格展示了哪些模式是互相冲突的:
在 Postgres 9.1 和 9.2 有两种行级锁模式,但在 Postgres 9.3 和 9.4 有四种行级锁模式。
Postgres 不会记住修改的行在内存中的任何信息,所以一次锁定的行的数目没有限制。然而,锁定一行可能会导致磁盘写入,例如,SELECT FOR UPDATE 修改选定的行并标记它们锁定,所以会导致磁盘写入。
1、Postgres 9.1 和 9.2 中的行级锁
在这两种版本中,只有 2 种行级锁:排他或共享锁。当行更新或删除时,会自动获得排他行级锁。行级锁不阻止数据查询,它们只阻止同一行写入。 排他行级锁可由 SELECT FOR UPDATE 命令明确获得,即使行没有实际更改。
共享行级锁可由 SELECT FOR SHARE 命令获得。一个共享锁并不阻止其他事务获取同样的共享锁。然而,当任何其他事务持有共享锁时,事务的更新、删除或排他锁都不被允许。
2、Postgres 9.3 和 9.4 中的行级锁
在 Postgres 9.3 和 9.4 中有四种类型的行级锁:
下面表格是关于行级锁冲突:
Postgres提供创建具有应用定义的锁的方法,这些被称为劝告锁(advisory locks),因为系统并不支持其使用,其取决于应用对锁的正确使用。
Postgres中有两种途径可以获得一个劝告锁:会话层级或事务层级。一旦在会话层级获得劝告锁,会一直保持到被显式释放或会话结束。不同于标准的锁请求,会话层级的劝告锁请求并不遵守事务语义:事务被回滚后锁也会随着回滚保持着,同样地即使调用锁的事务之后失败了,解锁请求仍然是有效的。一个锁可以被拥有它的进程多次获取;对于每个完成的锁请求,在锁被真正释放前一定要有一个对应的解锁请求。
另一方面,事务层级的锁请求表现得更像普通的锁请求:它们在事务结束时会自动释放,并且没有显式的解锁操作。对于短暂地使用劝告锁,这种特性通常比会话层级更方便。可以想见,会话层级与事务层级请求同一个劝告锁标识符会互相阻塞。如果一个会话已经有了一个劝告锁,它再请求时总会成功的,即使其他会话在等待此锁;不论保持现有的锁和新的请求是会话层级还是事务层级,都是这样。文档中可以找到操作劝告锁的完整函数列表。
这里有几个获取事务层级劝告锁的例子(pg_locks是系统视图,文章之后会说明。它存有事务保持的表级锁和劝告锁的信息):
启动第一个psql会话,开始一个事务并获取一个劝告锁:
-- Transaction 1BEGIN;SELECT pg_advisory_xact_lock(1);-- Some work here
现在启动第二个psql会话并在同一个劝告锁上执行一个新的事务:
-- Transaction 2BEGIN;SELECT pg_advisory_xact_lock(1);-- This transaction is now blocked
在第三个psql会话里我们可以看下这个锁现在的情况:
SELECT * FROM pg_locks; -- Only relevant parts of output
-- Transaction 1COMMIT;-- This transaction now released lock, so Transaction 2 can continue
所有活动事务持有的监控锁的基本配置即为系统视图 pg_locks。这个视图为每个可加锁的对象、已请求的锁模式和相关事务包含一行记录。非常重要的一点是,pg_locks 持有内存中被跟踪的锁的信息,所以它不显示行级锁!(译注:据查以前的文档,有关行级锁的信息是存在磁盘上,而非内存)这个视图显示表级锁和劝告锁。如果一个事务在等待一个行级锁,它通常在视图中显示为在等待该行级锁的当前所有者的固定事务 ID。这使得调试行级锁更为困难。事实上,在任何地方你都看不到行级锁,直到有人阻塞了持有此锁的事务(然后你在 pg_locks 表里可以看到一个被上锁的元组)。
pg_locks 是可读性欠佳的视图(不是很人性化),所以这里用一个显示锁定信息的视图来显示:
-- View with readable locks info and filtered out locks on system tablesCREATE VIEW active_locks ASSELECT clock_timestamp(), pg_class.relname, pg_locks.locktype, pg_locks.database, pg_locks.relation, pg_locks.page, pg_locks.tuple, pg_locks.virtualtransaction, pg_locks.pid, pg_locks.mode, pg_locks.grantedFROM pg_locks JOIN pg_class ON pg_locks.relation = pg_class.oidWHERE relname !~ '^pg_' and relname <> 'active_locks';-- Now when we want to see locks just typeSELECT * FROM active_locks;
后面会分享更多devops和DBA方面的内容,感兴趣的朋友可以关注一下~