Lock 等待

Lock 是最容易直接处置的一类：后端向锁管理器申请重量级锁，但不兼容的持有者尚未释放。与 LWLock 不同，这些等待通常在 pg_locks 中有对应行，pg_blocking_pids() 也能给出有效答案。

看阻塞图，不要只数受害者

二十个等待者可能都只是一个空闲事务的症状。先走到阻塞图最前端，再判断持有者是在做有效工作、已被遗弃，还是处于计划内 DDL/发布窗口。

• 正常： 普通写入或计划内 DDL 期间，亚秒级的锁交接。
• 关注： 任一面向用户的等待超过其延迟目标，或至少 10% 的活动会话等待同一个根阻塞者。
• 紧急： 根持有者是 idle in transaction、阻塞链持续增长、关键 DDL 阻塞流量，或死锁开始增加。

值得先认出的事件

阻塞者查询

SELECT w.pid AS waiting_pid, b.pid AS blocking_pid,
       w.wait_event, now() - w.query_start AS waiting_for,
       now() - b.xact_start AS blocker_xact_age,
       b.state AS blocker_state,
       left(w.query, 100) AS waiting_query,
       left(b.query, 100) AS blocking_query
FROM pg_stat_activity AS w
CROSS JOIN LATERAL unnest(pg_blocking_pids(w.pid)) AS x(pid)
JOIN pg_stat_activity AS b ON b.pid = x.pid
ORDER BY waiting_for DESC;

常见误读

• 被列为阻塞者的会话并不一定可以安全终止；它可能是维护业务不变量的唯一写入者。
• transactionid 不代表事务 ID 即将耗尽。
• relation 本身不说明具体关系；需要把 pg_locks.relation 关联到 pg_class。
• 增大 lock_timeout 只改变受害者等多久，并不会移除阻塞者。