plucky (7) lock.7.gz

Provided by: manpages-zh_1.6.4.2-1_all bug

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