我们在使用数据库时，经常遇到锁等待的事情。例如一个用户在更新一条记录时，另一个会话要更新同一条记录就需要等待。这种锁等待是比较显而易见的，有一些锁等待你可能会觉得匪夷所思。下面就由DBA+社群联合发起人周正中，跟大家聊聊这些“隐式”锁请求。

例如：

会话A：

会话B：

select * from pg_get_indexdef('test_pkey'::regclass);  -- 查询索引的定义

如果test_pkey是test的一个索引，它会进入等待状态。

我们来跟踪一下

首先请按照 http://blog.163.com/digoal@126/blog/static/163877040201422083228624  提供的方法开启LOCK DEBUG。

会话A：

会话B：

等待中。

使用 https://github.com/digoal/pgsql_admin_script/blob/master/generate_report.sh  提供的方法可以查询到锁等待如下：

此时提交或回归会话A，然后会话B可以继续：

正常情况下，查询索引定义如果没有被堵塞，观察到的锁是这样的：

还有很多获得对象定义的函数，使用时需要注意。

例如：

获取规则定义也要请求表的AccessShareLock。

会话A：

会话B：

pg_get_viewdef也有这个问题，需要获得视图引用的表的AccessShareLock。

另外再提供一个需要注意的点，PG对未获得，但是在等待中的锁也在冲突列表中。

例如用户1对A表在做一个比较大的查询，另一个用户2需要对A表执行DDL，那么显然用户2的DDL无法获得排它锁在等待用户1的状态。此后，用户3或其他用户发起对A的查询请求也会被用户2堵塞，这是非常危险的，如果用户1不释放锁，那么用户2就会一直等待，同时会堵塞所有对A表的任何请求。

所以建议用户在执行DDL操作时，加一个锁超时的参数，防止出现以上情况。

set lock_timeout='1s';

还有一种autocommit的场景下，建议对需要持有大锁的SQL在执行前加上语句超时，防止长时间持锁或等待锁，在某些场景甚至可能造成拥塞，例如短连接的场景，用户可能不断发起请求，把数据库连接用完。

set statement_timeout ='1s';

以上锁DEBUG信息都可以参考src/include/storage/lock.h获得详细的描述。