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 或轮询脚本。
- 简单判断：对每个
waiting = true的 PID，执行SELECT pg_blocking_pids(，再对结果里的 PID 重复查，手动展开两层通常就够用) - 防遗漏：优先筛选
state = 'active'且wait_event_type = 'Lock'的会话，它们更可能是“活阻塞源” - 注意
pg_blocking_pids()返回的是数组，要用unnest()展开才能 JOIN，否则容易丢行
哪些 wait_event 值容易被当成阻塞，其实不是？
wait_event_type = 'IO'（如 BufFileRead）、'Timer'（如 ClientRead）、'LWLock'（轻量锁）都不属于用户级锁冲突，不会出现在 pg_locks 的阻塞关系里。它们反映的是系统资源等待，和事务间锁无关。
-
wait_event = 'Lock'是唯一需联动pg_locks分析的类型 -
wait_event = 'ClientWrite'多半是网络慢或客户端没读响应，不是数据库堵了 - 若大量会话
waiting = true但wait_event_type是Client或IPC，先查网络和应用层，别一头扎进锁视图
真实阻塞往往藏在“空 query + idle in transaction + 长 xact_start”这三者的组合里，而不是显眼的 active 状态。轮询比单次快照可靠，递归比一层 pg_blocking_pids() 安全，而忽略 wait_event_type 直接看 waiting，等于关掉最重要的过滤器。
