在执行删除操作时对一个有主键的表进行 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;
兼容性 SQL92 在SQL92里面没有LOCK TABLE ,可以使用 SET TRANSACTION 来声明当前事务的级别. 我们也支持这个,参阅 SET TRANSACTION 获取详细信息。
行级锁 --for update
Name
LOCK — 在事务中明确地锁定一个表
LOCK [ TABLE ] name
LOCK [ TABLE ] name IN [ ROW | ACCESS ] { SHARE | EXCLUSIVE } MODE
LOCK [ TABLE ] name IN SHARE ROW EXCLUSIVE MODE
输入
name
要锁定的现存的表. ACCESS SHARE MODE
注意: 这个锁模式对被查询的表自动生效。 这是最小限制的锁模式,只与 ACCESS EXCLUSIVE 模式冲突。 它用于保护被查询的表免于被并行的 ALTER TABLE, DROP TABLE 和 VACUUM 对同一表操作的语句修改。 ROW SHARE MODE
注意: 任何 SELECT...FOR UPDATE 语句执行时自动生效。 因为它是一个共享锁,以后可能更新为 ROW EXCLUSIVE 锁。 与 EXCLUSIVE 和 ACCESS EXCLUSIVE 锁模式冲突。 ROW EXCLUSIVE MODE
注意: 任何 UPDATE, DELETE和 INSERT 语句执行时自动生效。 与 SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE 和 ACCESS EXCLUSIVE 模式冲突。 SHARE MODE
注意: 任何 CREATE INDEX 语句执行时自动附加。 共享锁住整个表. 与 ROW EXCLUSIVE,SHARE ROW EXCLUSIVE,EXCLUSIVE 和 ACCESS EXCLUSIVE 模式冲突。这个模式防止一个表被并行更新。 SHARE ROW EXCLUSIVE MODE
注意: 这个模式类似 EXCLUSIVE MODE,但是允许其他事务的 SHARE ROW 锁. 与 ROW EXCLUSIVE,SHARE,SHARE ROW EXCLUSIVE,EXCLUSIVE 和 ACCESS EXCLUSIVE 模式冲突。 EXCLUSIVE MODE
注意: 这个模式同样比 SHARE ROW EXCLUSIVE 更有约束力. 它阻塞所有并行的 ROW SHARE/SELECT... FOR UPDATE 查询。 与 ROW EXCLUSIVE,SHARE,SHARE ROW EXCLUSIVE,EXCLUSIVE 和 ACCESS EXCLUSIVE 模式冲突。 ACCESS EXCLUSIVE MODE
注意: 由语句 ALTER TABLE, DROP TABLE,VACUUM 执行时自动生效。这是最严格的约束锁,它与所有其他的锁 模式冲突并且保护一个被锁定的表不被任何其他并行的操作更改。 注意: 一个不合格的 LOCK TABLE 同样要求这个锁模式 (例如,一条没有显式锁模式选项的命令)。
输出
LOCK TABLE
成功锁定后的返回. ERROR name: Table does not exist.
如果name 不存在,返回此信息.
描述
LOCK TABLE 控制一次事务的生命期内对某表的并行访问. Postgres 在可能的情况下尽可能使用最小约束的锁模式。 LOCK TABLE 在你需要时提供更有约束力的锁。 RDBMS 锁定使用下面术语:
EXCLUSIVE
排它锁,防止其他(事务)锁的产生. SHARE
允许其他(事务)共享锁.避免 EXCLUSIVE 锁. ACCESS
锁定表结构. ROW
锁定独立的行. 注意: 如果没有声明 EXCLUSIVE 或 SHARE,假设为 EXCLUSIVE.锁存在于事务周期内.
例如,一个应用在 READ COMMITED 隔离级别上运行事务, 并且它需要保证在表中的数据在事务的运行过程中都存在。要实现这个你 可以在查询之前对表使用 SHARE 锁模式进行锁定。这样将保护数据不被 并行修改并且为任何更进一步的对表的读操作提供实际状态的数据, 因为 SHARE 锁模式与任何写操作需要的 ROW EXCLUSIVE 模式冲突,并且你的 LOCK TABLE name IN SHARE MODE 语句将等到所有并行的写操作提交或回卷后才执行。 注意: 当在 SERIALIZABLE 隔离级别运行事务,而且你需要读取真实状态的数据时, 你必须在执行任何 DML 语句 (这时事务定义什么样的并行修改对它自己是可见的) 之前运行一个 LOCK TABLE 语句。
除了上面的要求外,如果一个事务准备修改一个表中的数据, 那么应该使用 SHARE ROW EXCLUSIVE 锁模式以避免死锁情况(当两个 并行的事务试图以 SHARE 模式锁住表然后试图更改表中的数据时, 两个事务(隐含的)都需要 ROW EXCLUSIVE 锁模式,而此模式与并行的 SHARE 锁冲突)。 继续上面的死锁(两个事务彼此等待)问题, 你应该遵循两个通用的规则以避免死锁条件:
事务应该以相同的顺序对相同的对象请求锁。 例如,如果一个应用更新行 R1 然后更新行 R2(在同一的事务里), 那么第二个应用如果稍后要更新行 R1 时不应该更新行 R2(在 同一事务里)。相反,它应该与第一个应用以相同的顺序更新行 R1 和 R2。 事务请求两个互相冲突的锁模式的前提:其中一个锁模式是自冲突的 (也就是说,一次只能被一个事务持有)。 如果涉及多种锁模式,那么事务应该总是最先请求最严格的锁模式。 这个规则的例子在前面的关于用 SHARE ROW EXCLUSIVE 模式取代 SHARE 模式的讨论中已经给出了。 注意: Postgres 的确检测死锁, 并将回卷至少一个等待的事务以解决死锁。 注意
LOCK 是 Postgres 语言扩展. 除了ACCESS SHARE/EXCLUSIVE 锁模式外,所有其他 Postgres 锁模式和 LOCK TABLE 语句都与那些在 Oracle 里面的兼容。 LOCK 只在事务内部使用. 用法
演示在往一个外键表上插入时在有主键的表上使用 SHARE 的锁: BEGIN WORK;
LOCK TABLE films IN SHARE MODE;
SELECT id FROM films
WHERE name = 'Star Wars: Episode I - The Phantom Menace';
-- 如果记录没有返回则回卷
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;
兼容性
SQL92
在SQL92里面没有LOCK TABLE ,可以使用 SET TRANSACTION 来声明当前事务的级别. 我们也支持这个,参阅 SET TRANSACTION 获取详细信息。