LOCK - 明确地锁定一个表

标签：死锁   sql   ble   行锁   ``   nop   mode   自动   table   

SYNOPSIS

LOCK [ TABLE ] name [, ...] [ IN lockmode MODE ]

where lockmode is one of:

    ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE
    | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE

DESCRIPTION 描述

LOCK TABLE 获取一个表级锁，必要时等待任何冲突的锁释放。 一旦获取了这个锁，它就会在当前事务的余下部分一直保持。 （没有 UNLOCK TABLE 命令；锁总是在事务结尾释放。）

 在为那些引用了表的命令自动请求锁的时候，PostgreSQL 总是尽可能使用最小限制的锁模式。LOCK TABLE  是为你在需要更严格的锁的场合提供的。 例如，假设一个应用在读已提交隔离级别上运行事务， 并且它需要保证在表中的数据在事务的运行过程中都存在。要实现这个目的， 你可以在查询之前对表使用 SHARE 锁模式进行锁定。 这样将保护数据不被并行修改并且为任何更进一步的对表的读操作提供实际的当前状态的数据， 因为 SHARE 锁模式与任何写操作需要的 ROW EXCLUSIVE 模式冲突， 并且你的 LOCK TABLE name IN SHARE MODE  语句将等到所有并行的写操作提交或回卷后才执行。因此，一旦你获得该锁，那么就不会存在未提交的写操作．

 如果运行在可串行化隔离级别并且你需要读取真实状态的数据时， 你必须在执行任何数据修改语句之前运行一个 LOCK TABLE 语句。 一个可串行化事务的数据图象将在其第一个数据修改语句开始的时候冻结住。 稍后的 LOCK TABLE 将仍然阻止并发的写 －－－ 但它不能保证事务读取的东西对应最近提交的数值。

 如果一个此类的事务准备修改一个表中的数据，那么应该使用 SHARE ROW EXCLUSIVE 锁模式，而不是 SHARE 模式。 这样就保证任意时刻只有一个此类的事务运行。不这样做就可能会死锁： 当两个并行的事务可能都请求 SHARE 模式，然后试图更改表中的数据时， 两个事务在实际执行更新的时候都需要 ROW EXCLUSIVE 锁模式， 但是它们无法再次获取这个锁。（请注意，一个事务自己的锁是从不冲突的， 因此一个事务可以在持有 SHARE 模式的锁的时候请求 ROW EXCLUSIVE 模式－－但是不能在任何其它事务持有 SHARE  模式的时候请求。） 为了避免死锁，所有事务应该保证以相同的顺序对相同的对象请求锁， 并且，如果涉及多种锁模式，那么事务应该总是最先请求最严格的锁模式。

 有关锁模式和锁定策略的更多信息，请参考 Section 12.3 ``Explicit Locking‘‘ 。

PARAMETERS 参数

name

 要锁定的现存表的名字（可以有模式修饰）。

 命令 LOCK a, b; 等效于 LOCK a; LOCK b;。 表是按照 LOCK 命令中声明的顺序一个接一个顺序上锁的。

lockmode

 锁模式声明这个锁和那些锁冲突。锁模式在 Section 12.3 ``Explicit Locking‘‘ 里描述。

 如果没有声明锁模式，那么使用最严格的模式 ACCESS EXCLUSIVE。

NOTES 注意

LOCK ... IN ACCESS SHARE MODE 需要在目标表上有 SELECT 权限。所有其它形式的 LOCK 需要 UPDATE 和/或 DELETE 权限。

LOCK 只是在一个事务块的内部有用 （BEGIN...COMMIT），因为锁在事务结束的时候马上被释放。 出现在任意事务块外面的 LOCK 都自动生成一个自包含的事务，因此该锁在获取之后马上被丢弃。

LOCK TABLE 只处理表级的锁，因此那些有 ROW 字样的锁都是用词不当。这些模式名字通常应该应该理解为用户视图在一个被锁定的表中获取行级的锁。 同样 ROW EXCLUSIVE 模式也是一个可共享的表级锁。 我们一定要记住，只要是涉及到 LOCK TABLE， 那么所有锁模式都有相同的语意，区别只是它们与哪种锁冲突的规则。

EXAMPLES 例子

 演示在往一个外键表上插入时在有主键的表上使用 SHARE 的锁：

BEGIN WORK;
LOCK TABLE films IN SHARE MODE;
SELECT id FROM films 
    WHERE name = ‘Star Wars: Episode I - The Phantom Menace‘;
-- Do ROLLBACK if record was not returned
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;

LOCK - 明确地锁定一个表

标签：死锁   sql   ble   行锁   ``   nop   mode   自动   table   

原文地址：https://www.cnblogs.com/fanweisheng/p/11089198.html