下面的列表展示了可用的锁模式，以及 PostgreSQL 自动使用它们的场景。 请记住，所有这些锁模式都是表级锁，即使名称中包含 “row”（行）一词也是如此；这些锁模式的名称是历史遗留的。名称在某种程度上反映了每种锁模式的典型用法——但语义都是一样的。一种锁模式与另一种的唯一实质区别，是各自与之冲突的锁模式集合。两个事务不能同时在同一张表上持有相互冲突模式的锁。（不过，事务永远不会与自身冲突。例如，一个事务可以先取得 ACCESS EXCLUSIVE 锁，之后再在同一张表上取得 ACCESS SHARE 锁。）不冲突的锁模式可以由多个事务同时持有。特别要注意，有些锁模式是自冲突的（例如， ACCESS EXCLUSIVE 锁同一时刻只能被一个事务持有），而另一些不是自冲突的（例如， ACCESS SHARE 锁可以被多个事务持有）。锁一旦取得，就会保持到事务结束。

除了表级锁之外，还有行级锁。当某一行被更新（或删除或标记为更新）时，会自动获得该特定行上的行级锁。这种锁一直保持到事务提交或回滚为止。行级锁不影响数据查询；它们只会阻塞对同一行的写入者。要在不实际修改某行的情况下获取该行上的行级锁，可以使用SELECT FOR UPDATE选择该行。注意，一旦获得了特定的行级锁，事务就可以多次更新该行而无须担心冲突。

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 会检测到这种情况，并中止其中一个事务。

防范死锁的最佳办法通常是通过确保所有使用数据库的应用以一致的顺序在多个对象上获取锁来避免死锁。前面死锁例子的原因正在于此：如果两个事务以相同的顺序更新行，就不会发生死锁。还应确保事务在一个对象上首先获取的锁是该对象所需的最高模式。如果无法提前验证这一点，那么可以在运行时重试因死锁而中止的事务来处理死锁。

只要没有检测到死锁，寻求表级锁或行级锁的事务就会无限期等待冲突锁被释放。这意味着让应用长时间保持事务打开并不是好主意（例如等待用户输入时）。