NAME

       LOCK - 明确地锁定一个表

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;

COMPATIBILITY 兼容性

        在   SQL   标准里面没有LOCK   TABLE  ，可以使用  SET  TRANSACTION  来声明当前事务的级别。
       PostgreSQL 也支持这个，参阅 SET TRANSACTION [set_transaction(7)] 获取详细信息。

        除了 ACCESS SHARE，ACCESS EXCLUSIVE，和 SHARE UPDATE EXCLUSIVE  锁模式外， PostgreSQL  锁
       模式和 LOCK TABLE 语句都与那些在 Oracle 里面的兼容。

译者

       Postgresql 中文网站 何伟平 <laser@pgsqldb.org>

跋

       本页面中文版由中文 man 手册页计划提供。
       中文 man 手册页计划：https://github.com/man-pages-zh/manpages-zh