pg_stat_activity.waiting = true 仅表示会话当前等待某个事件，未必是锁阻塞；需结合wait_event_type=’lock’确认锁等待，而’idle in transaction’长时间未提交也会持锁阻塞他人。
pg_stat_activity.waiting = true 说明什么？
它只代表这个会话当前正在等一个锁，但不告诉你等的是哪种锁、等谁、等多久——waiting 是布尔开关，不是诊断终点。真正关键的是结合 wait_event_type 和 wait_event 字段：当 wait_event_type = 'Lock' 才是典型锁阻塞；若为 'Client' 或空值，大概率是持锁方而非等待方。
为什么 state = ‘idle in transaction’ 却还在阻塞别人？
这是最常被误判的场景：事务已执行完 SQL，没提交也没回滚，锁一直挂着，但 query 字段早已为空，state 却卡在 idle in transaction。此时看 xact_start 和 backend_start 的时间差，如果差值远大于业务预期（比如几分钟甚至几小时），基本就是“幽灵事务”在持锁。
-
pg_stat_activity.query为空 ≠ 没在干活，只是没新语句进来 - 用
NOW() - xact_start判断事务存活时长，比看query_start更可靠 - 这类会话查不到 SQL，得靠日志（
log_min_duration_statement）或应用侧回溯
如何从 pg_stat_activity 快速定位阻塞链起点？
别依赖单次 pg_blocking_pids(pid) —— 它只返回直接阻塞者，A→B→C 的嵌套阻塞里，查 A 只看到 B，漏掉 C。真要抓全链，必须用递归 CTE 或轮询脚本。
