概述

锁机制在 PostgreSQL 里非常重要 ，对于DBA（特别是那些涉及到高并发代码的程序员），需要对锁非常熟悉。特别是某些问题，锁需要被重点关注与检查。大部分情况，这些问题跟死锁或者数据不一致有关系，基本上都是由于对 Postgres 的锁机制不太了解导致的。

3种锁机制

Postgres 有 3 种锁机制：表级锁，行级锁和建议性锁。表级和行级的锁可以是显式的也可以是隐式的。建议性锁一般是显式的。显式的锁由显式的用户请求（通过特殊的查询）获取，隐式的锁是通过标准的 SQL 命令来获取。

除了表级和行级的锁，还有页级共享/排除锁，用于控制对共享缓存池里表页的访问。在一行数据被读取或者更新后，这些锁会立即被释放。应用程序开发者通常不需要关注页级的锁。

表级锁

大多数的表级锁是由内置的 SQL 命令获得的，但也可以通过锁命令来明确获取。可使用的表级锁包括：

• 访问共享（ACCESS SHARE） – SELECT 命令可在查询中引用的表上获得该锁。一般规则是所有的查询中只有读表才获取此锁。
• 行共享（ROW SHARE） – SELECT FOR UPDATE 和 SELECT FOR SHARE 命令可在目标表上获得该锁（以及查询中所有引用的表的访问共享锁）。
• 行独占（ROW EXCLUSIVE） – UPDATE、INSERT 和 DELETE 命令在目标表上获得该锁（以及查询中所有引用的表的访问共享锁）。 一般规则是所有修改表的查询获得该锁。
• 共享更新独占（SHARE UPDATE EXCLUSIVE） – VACUUM（不含FULL），ANALYZE，CREATE INDEX CONCURRENTLY，和一些 ALTER TABLE 的命令获得该锁。
• 共享（SHARE） – CREATE INDEX 命令在查询中引用的表上获得该锁。
• 共享行独占（SHARE ROW EXCLUSIVE） – 不被任何命令隐式获取。
• 排他（EXCLUSIVE） – 这个锁模式在事务获得此锁时只允许读取操作并行。它不能由任何命令隐式获取。
• 访问独占（ACCESS EXCLUSIVE） – ALTER TABLE，DROP TABLE，TRUNCATE，REINDEX，CLUSTER 和 VACUUM FULL 命令在查询中引用的表上获得该锁。此锁模式是 LOCK 命令的默认模式。

重要的是要知道，所有这些锁都是表级锁，即使它们名称里有行（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 中有四种类型的行级锁:

• 更新（FOR UPDATE） – 这种模式导致 SELECT 读取的行的更新被锁定。这可以防止它们被其他事务锁定，修改或删除。即尝试 UPDATE、DELETE、SELECT FOR UPDATE、SELECT FOR NO KEY UPDATE、SELECT FOR SHARE 或 SELECT FOR KEY SHARE 的其他事务将被阻塞。删除一行，更新一些列也可以获得到此种锁模式（目前的列集是指那些具有唯一索引，并且可被用作外键 – 但将来这可能会改变）。
• 无键更新（FOR NO KEY UPDATE） – 这种模式与 FOR UPDATE 相似，但是更弱 – 它不会阻塞SELECT FOR KEY SHARE 锁模式。它通过不获取更新锁的 UPDATE 命令获得。
• 共享（FOR SHARE） – 这种模式与无键更新锁类似，除了它可以获取共享锁（非排他）。一个共享锁阻止其他事务在这些行上进行 UPDATE，DELETE，SELECT FOR UPDATE 或 SELECT FOR NO KEY UPDATE 操作，但并不阻止它们进行 SELECT FOR SHARE 或 SELECT FOR KEY SHARE。
• 键共享（FOR KEY SHARE）– 行为类似于共享，但该锁是较弱的：阻止了 SELECT FOR UPDATE，但不阻止 SELECT FOR NO KEY UPDATE。一个键共享锁阻止其他事务进行 DELETE 或任何更改该键值的 UPDATE，但不妨碍任何其他 UPDATE、SELECT FOR NO KEY UPDATE、SELECT FOR SHARE 或者SELECT FOR KEY SHARE。

下面表格是关于行级锁冲突：

劝告锁

Postgres提供创建具有应用定义的锁的方法，这些被称为劝告锁（advisory locks），因为系统并不支持其使用，其取决于应用对锁的正确使用。

Postgres中有两种途径可以获得一个劝告锁：会话层级或事务层级。一旦在会话层级获得劝告锁，会一直保持到被显式释放或会话结束。不同于标准的锁请求，会话层级的劝告锁请求并不遵守事务语义：事务被回滚后锁也会随着回滚保持着，同样地即使调用锁的事务之后失败了，解锁请求仍然是有效的。一个锁可以被拥有它的进程多次获取；对于每个完成的锁请求，在锁被真正释放前一定要有一个对应的解锁请求。

另一方面，事务层级的锁请求表现得更像普通的锁请求：它们在事务结束时会自动释放，并且没有显式的解锁操作。对于短暂地使用劝告锁，这种特性通常比会话层级更方便。可以想见，会话层级与事务层级请求同一个劝告锁标识符会互相阻塞。如果一个会话已经有了一个劝告锁，它再请求时总会成功的，即使其他会话在等待此锁；不论保持现有的锁和新的请求是会话层级还是事务层级，都是这样。文档中可以找到操作劝告锁的完整函数列表。

这里有几个获取事务层级劝告锁的例子（pg_locks是系统视图，文章之后会说明。它存有事务保持的表级锁和劝告锁的信息）：

启动第一个psql会话，开始一个事务并获取一个劝告锁：

-- Transaction 1
BEGIN;
SELECT pg_advisory_xact_lock(1);
-- Some work here

欢迎大家来到IT世界,在知识的湖畔探索吧!

现在启动第二个psql会话并在同一个劝告锁上执行一个新的事务：

欢迎大家来到IT世界,在知识的湖畔探索吧!-- Transaction 2
BEGIN;
SELECT pg_advisory_xact_lock(1);
-- This transaction is now blocked

在第三个psql会话里我们可以看下这个锁现在的情况：

SELECT * FROM pg_locks; -- Only relevant parts of output 

欢迎大家来到IT世界,在知识的湖畔探索吧!-- Transaction 1
COMMIT;
-- 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 tables
CREATE VIEW active_locks AS
SELECT 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.granted
FROM pg_locks JOIN pg_class ON pg_locks.relation = pg_class.oid
WHERE relname !~ '^pg_' and relname <> 'active_locks';
-- Now when we want to see locks just type
SELECT * FROM active_locks;

后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注一下~