表级锁模式

ACCESS SHARE
只与 ACCESS EXCLUSIVE 冲突。

SELECT 和 ANALYZE 命令在被引用的表上请求一个这种锁。 通常，任何只读取表而不修改它的命令都请求这种锁模式。

ROW SHARE
与EXCLUSIVE和ACCESS EXCLUSIVE模式冲突。

SELECT FOR UPDATE 和 SELECT FOR SHARE 命令在目标表上需要一个这样模式的锁（加上在所有被引用但没有 FOR UPDATE/FOR SHARE 的表上的 ACCESS SHARE 锁）。

ROW EXCLUSIVE
与 SHARE，SHARE ROW EXCLUSIVE， EXCLUSIVE 和 ACCESS EXCLUSIVE 模式冲突。

命令 UPDATE，DELETE， 和 INSERT 自动请求这个锁模式。 （加上所有其它被引用的表上的 ACCESS SHARE 锁）。 通常，这种锁将被任何修改表中数据的查询请求。

SHARE UPDATE EXCLUSIVE
和 SHARE UPDATE EXCLUSIVE，SHARE， SHARE ROW EXCLUSIVE，EXCLUSIVE， 和 ACCESS EXCLUSIVE 模式冲突。 这个模式保护一个表不被并发模式改变和 VACUUM。

VACUUM（不带 FULL 选项）请求这样的锁。

SHARE
与 ROW EXCLUSIVE，SHARE UPDATE EXCLUSIVE， SHARE ROW EXCLUSIVE，EXCLUSIVE 和 ACCESS EXCLUSIVE 模式冲突。 这个模式避免表的并发数据修改。

CREATE INDEX 语句要求这样的锁模式。

SHARE ROW EXCLUSIVE
与 ROW EXCLUSIVE， SHARE UPDATE EXCLUSIVE，SHARE， SHARE ROW EXCLUSIVE，EXCLUSIVE， 和 ACCESS EXCLUSIVE 模式冲突。

任何 PostgreSQL 命令都不会自动请求这样的锁模式。

EXCLUSIVE
与 ROW SHARE，ROW EXCLUSIVE， SHARE UPDATE EXCLUSIVE， SHARE，SHARE ROW EXCLUSIVE， EXCLUSIVE 和 ACCESS EXCLUSIVE 模式冲突。 这个模式只允许并发 ACCESS SHARE 锁，也就是说， 只有对表的读动作可以和持有这个锁模式的事务并行执行。

任何 PostgreSQL 命令都不会在用户表上自动请求这样的锁模式． 不过，在有些操作的时候，会在某些系统表上请求它。

ACCESS EXCLUSIVE
与所有模式冲突。 （ ACCESS SHARE, ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, 和 ACCESS EXCLUSIVE). 这个模式保证其所有者（事务）是可以用任意方式访问该表的唯一事务。

ALTER TABLE， DROP TABLE，REINDEX，CLUSTER和 VACUUM FULL 命令要求这样的锁。 在 LOCK TABLE 命令没有明确声明需要的锁模式时，它也是缺省锁模式。

提示: 只有 ACCESS EXCLUSIVE 阻塞 SELECT （没有 FOR UPDATE/FOR SHARE语句）。

除了表级锁以外，还有行级锁，他们可以是排他的或者是共享的。 特定行上的排他行级锁是在行被更新的时候自动请求的。 该锁一直保持到事务提交或者回滚。 行级锁不影响对数据的查询； 它们只阻塞对同一行的写入。

要在不修改某行的前提下请求在该行的一个排他行级锁，用 SELECT FOR UPDATE 选取该行。 请注意一旦我们请求了特定的行级锁， 那么该事务就可以多次对该行进行更新而不用担心冲突。

要在一行上请求一个共享的行级锁，用 SELECT FOR SHARE 选取该行。 一个共享锁并不阻止其它事务请求同一个共享的锁。不过，其它事务不允许更新，删除， 或者排他锁住一个其它事务持有共享锁的行。任何这么做的企图都将被阻塞住，等待共享锁释放。

PostgreSQL 不会在内存里保存任何关于已修改行的信息， 因此对一次锁定的行数没有限制。 不过，锁住一行会导致一次磁盘写；因此，象 SELECT FOR UPDATE 将修改选中的行以标记它们被锁住了， 因此会导致磁盘写。

除了表级别的和行级别的锁以外， 页面级别的共享/排他销也用于控制对共享缓冲池中表页面的读/写访问。 这些锁在抓取或者更新一行后马上被释放。 应用程序员通常不需要关心页级锁，我们在这里提到它们只是为了完整。

明确锁定的使用可能会增加死锁的可能性， 死锁是是指两个（或多个）事务相互持有对方期待的锁。比如， 如果事务 1 在表 A上持有一个排他锁， 同时试图请求一个在表 B 上的排他锁， 而事务 2 已经持有表B的排他锁，而却正在请求在表 A上的一个排他锁，那么两个事务就都不能执行。 PostgreSQL 自动侦测到死锁条件并且会通过退出一个当事的事务来解决这个问题， 以此来允许其它事务完成。（具体哪个事务会被退出是很难预计的，而且也不应该依靠这样的预计。）

要注意的是死锁也可能会因为行级锁而发生（因此，即使是没有使用明确的锁定，也可能发生）。 考虑这样一种情况，两个并发事务在修改一个表。第一个事务执行了：

UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 11111;这样就在指定帐号的行上请求了一个行级锁。然后，第二个事务执行：

UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 22222;
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 11111;第一个 UPDATE 语句成功地在指定行上请求到了一个行级锁，因此它成功更新了该行。 但是第二个 UPDATE 语句发现它试图更新地行已经被锁住了， 因此它等待持有该锁的事务结束。事务二现在就在等待事务一结束，然后再继续执行。 现在，事务一执行：

UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;事务一企图在指定行上请求一个行级锁，但是它得不到：事务二已经持有这样的锁了。 所以它等待事务二完成。因此，事务一被事务二阻塞住了，而事务二也被事务一阻塞住了：这就是一个死锁条件。 PostgreSQL 将侦测这样的条件并退出其中一个事务。

防止死锁的最好方法通常是保证所有使用一个数据库的应用都以一致的顺序在多个对象上请求锁定。 在上面的例子里，如果两个事务以同样的顺序更新那些行，那么就不会发生死锁。 我们也要保证在一个对象上请求的第一个锁是该对象需要的最高的锁模式。 如果我们无法提前核实这些问题，那么我们可以通过在现场重新尝试因死锁而退出的事务的方法来处理。

只要没有检测到死锁条件，一个等待表级锁或者行级锁的事务将等待冲突锁的释放不确定的时间。 这就意味着一个应用持有打开的事务时间太长可不是什么好事情（比如锁，等待用户输入）。

辛苦了！！