描述

LOCK TABLE 获取一个表级锁，必要时会等待任何冲突的锁被释放。一旦取得，该锁会保持到当前事务结束。（没有 UNLOCK TABLE 命令；锁总是在事务结束时释放。）

在为引用表的命令自动获取锁时，PostgreSQL 总是使用限制性最低的锁模式。LOCK TABLE 用于你可能需要更严格锁定的场合。

例如，假设一个应用以 READ COMMITTED 隔离级别运行事务，并且需要确保表中的数据在事务期间保持稳定。为此，你可以在查询之前对该表取得 SHARE 锁模式。这将阻止并发数据更改，并确保随后对该表的读取看到已提交数据的稳定视图，因为 SHARE 锁模式与写者取得的 ROW EXCLUSIVE 锁冲突，而你的 LOCK TABLE name IN SHARE MODE 语句会等待任何并发持有 ROW EXCLUSIVE 模式锁的事务提交或回滚。因此，一旦你取得了锁，就不存在未提交的写；而且在释放锁之前也不会有新的写开始。

如果这类事务要更改表中的数据，就应使用 SHARE ROW EXCLUSIVE 锁模式而不是 SHARE 模式。这确保同一时刻只有一个这类事务在运行。否则可能出现死锁：两个事务可能都取得了 SHARE 模式，然后又都无法再取得 ROW EXCLUSIVE 模式来实际执行更新。（注意，事务自身的锁永不冲突，因此持有 SHARE 模式的事务可以再取得 ROW EXCLUSIVE 模式——但如果别人持有 SHARE 模式则不行。）

为防止死锁条件，可以遵循两条通用规则：

PostgreSQL 确实会检测死锁，并会回滚至少一个等待中的事务来解决死锁。如果让应用严格遵循上述规则不现实，另一个解决办法是准备好在事务被死锁中止时重试它们。

锁定多个表时，命令 LOCK a, b; 等价于 LOCK a; LOCK b;。各表按 LOCK 命令中指定的顺序逐一锁定。

用法

在准备向外键表执行插入时，在主键表上获取一个 SHARE 锁：

BEGIN WORK;
LOCK TABLE films IN SHARE MODE;
SELECT id FROM films
    WHERE name = 'Star Wars: Episode I - The Phantom Menace';
-- 如果未返回记录则执行 ROLLBACK
INSERT INTO films_user_comments VALUES
    (_id_, 'GREAT! I was waiting for it for so long!');
COMMIT WORK;
   

在准备执行删除操作时，在主键表上获取一个 SHARE ROW EXCLUSIVE 锁：

BEGIN WORK;
LOCK TABLE films IN SHARE ROW EXCLUSIVE MODE;
DELETE FROM films_user_comments WHERE id IN
    (SELECT id FROM films WHERE rating < 5);
DELETE FROM films WHERE rating < 5;
COMMIT WORK;
   

兼容性