跳转到主要内容

这是本节的多页打印视图。 .

返回本页常规视图.

IPC 等待

PostgreSQL 进程等待对端、worker、屏障、队列或阶段变化。

IPC 表示协调：当前进程已经走到一个依赖另一个 PostgreSQL 进程或执行参与者的位置。对端可能是并行 worker、WAL receiver、checkpointer、archiver、复制进程，或共享内存协议里的另一个后端。

找到缺席的对端或阶段

等待者本身往往是健康的。先问谁应该向它发信号，再检查该参与者的状态。并行查询事件按阶段图阅读；复制事件按 sender/receiver 流水线阅读；检查点事件按全局屏障阅读。

  • 正常： 并行计划汇合、检查点开始/完成、worker 启动或同步复制中的短暂等待。
  • 关注： 前台等待者连续三次采样都停在同一阶段，而对端没有可见进展。
  • 紧急： 对端已退出或被阻塞、队列无法排空、复制/故障切换停滞，或大量会话依赖同一个卡住的协调者。

值得先认出的事件

事件 对端或阶段
BufferIo 正在为共享缓冲区执行 I/O 的另一个后端
ExecuteGather 向 Gather 节点提供数据的子进程
ParallelFinish 并行 worker 到达计划完成点
CheckpointDone checkpointer 完成请求的检查点
SyncRep 远端同步备库确认
WalReceiverWaitStart startup 进程等待流复制数据
MessageQueueReceive 共享内存消息队列的生产者
RecoveryPause 恢复被运维策略有意暂停

常见误读

  • 杀掉等待者无法修复已死亡或被阻塞的对端。
  • IPC/SyncRep 是确认延迟；LWLock/SyncRep 是共享队列/状态元数据上的竞争。
  • 许多并行等待名称本来就是屏障。真正的问题是所有参与者是否最终推进。
  • RecoveryPause 可能完全是有意行为；先检查 pg_is_wal_replay_paused()。

1 - IPC: AppendReady

等待 Append 计划节点的子计划节点就绪。
PostgreSQL 等待事件档案
类别IPC 事件AppendReady 版本PG 14-18 证据2 个源码位置

官方描述译文

等待 Append 计划节点的子计划节点就绪。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_APPEND_READY 位于 src/backend/executor/nodeAppend.c:1079，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:106。探针覆盖的操作是：等待 Append 计划节点的子计划节点就绪。AppendReady 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/AppendReady 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'AppendReady'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'AppendReady'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

2 - IPC: ArchiveCleanupCommand

等待 archive_cleanup_command 完成。
PostgreSQL 等待事件档案
类别IPC 事件ArchiveCleanupCommand 版本PG 15-18 证据2 个源码位置

官方描述译文

等待 archive_cleanup_command 完成。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_ARCHIVE_CLEANUP_COMMAND 位于 src/backend/access/transam/xlog.c:7885，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:107。探针覆盖的操作是：等待 archive_cleanup_command 完成。ArchiveCleanupCommand 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/ArchiveCleanupCommand 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'ArchiveCleanupCommand'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'ArchiveCleanupCommand'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

3 - IPC: ArchiveCommand

等待 archive_command 完成。
PostgreSQL 等待事件档案
类别IPC 事件ArchiveCommand 版本PG 15-18 证据2 个源码位置

官方描述译文

等待 archive_command 完成。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_ARCHIVE_COMMAND 位于 src/backend/archive/shell_archive.c:79，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:108。探针覆盖的操作是：等待 archive_command 完成。ArchiveCommand 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/ArchiveCommand 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'ArchiveCommand'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'ArchiveCommand'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

4 - IPC: BackendTermination

等待另一个后端终止。
PostgreSQL 等待事件档案
类别IPC 事件BackendTermination 版本PG 14-18 证据2 个源码位置

官方描述译文

等待另一个后端终止。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_BACKEND_TERMINATION 位于 src/backend/storage/ipc/signalfuncs.c:210，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:109。探针覆盖的操作是：等待另一个后端终止。BackendTermination 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/BackendTermination 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'BackendTermination'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'BackendTermination'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

5 - IPC: BackupWaitWalArchive

等待备份所需的 WAL 文件成功归档。
PostgreSQL 等待事件档案
类别IPC 事件BackupWaitWalArchive 版本PG 13-18 证据2 个源码位置

官方描述译文

等待备份所需的 WAL 文件成功归档。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_BACKUP_WAIT_WAL_ARCHIVE 位于 src/backend/access/transam/xlog.c:9405，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:110。探针覆盖的操作是：等待备份所需的 WAL 文件成功归档。BackupWaitWalArchive 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/BackupWaitWalArchive 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'BackupWaitWalArchive'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'BackupWaitWalArchive'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

6 - IPC: BgworkerShutdown

等待后台工作进程关闭。
PostgreSQL 等待事件档案
类别IPC 事件BgworkerShutdown 版本PG 17-18 证据4 个源码位置

官方描述译文

等待后台工作进程关闭。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

历史名称：IPC/BgWorkerShutdown (PG 13-16)

触发机制

WAIT_EVENT_BGWORKER_SHUTDOWN 位于 src/backend/postmaster/bgworker.c:1188，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:329。探针覆盖的操作是：等待后台工作进程关闭。BgworkerShutdown 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/BgworkerShutdown 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'BgworkerShutdown'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'BgworkerShutdown'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

7 - IPC: BgworkerStartup

等待后台工作进程启动。
PostgreSQL 等待事件档案
类别IPC 事件BgworkerStartup 版本PG 17-18 证据4 个源码位置

官方描述译文

等待后台工作进程启动。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

历史名称：IPC/BgWorkerStartup (PG 13-16)

触发机制

WAIT_EVENT_BGWORKER_STARTUP 位于 src/backend/access/transam/parallel.c:771，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:332。探针覆盖的操作是：等待后台工作进程启动。BgworkerStartup 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/BgworkerStartup 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'BgworkerStartup'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'BgworkerStartup'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

8 - IPC: BtreePage

等待继续并行 B-tree 扫描所需的页号可用。
PostgreSQL 等待事件档案
类别IPC 事件BtreePage 版本PG 13-18 证据2 个源码位置

官方描述译文

等待继续并行 B-tree 扫描所需的页号可用。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_BTREE_PAGE 位于 src/backend/access/nbtree/nbtree.c:927，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:113。探针覆盖的操作是：等待继续并行 B-tree 扫描所需的页号可用。BtreePage 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/BtreePage 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'BtreePage'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'BtreePage'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

9 - IPC: BufferIo

等待缓冲区 I/O 完成。
PostgreSQL 等待事件档案
类别IPC 事件BufferIo 版本PG 17-18 证据7 个源码位置

官方描述译文

等待缓冲区 I/O 完成。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

历史名称：IPC/BufferIO (PG 14-16), LWLock/BufferIO (PG 13)

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:765，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/xact.c:2627。探针覆盖的操作是：等待缓冲区 I/O 完成。BufferIo 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/BufferIo 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'BufferIo'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'BufferIo'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

10 - IPC: CheckpointDelayComplete

等待后端解除对检查点完成的阻塞。
PostgreSQL 等待事件档案
类别IPC 事件CheckpointDelayComplete 版本PG 17-18 证据2 个源码位置

官方描述译文

等待后端解除对检查点完成的阻塞。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

触发机制

WAIT_EVENT_CHECKPOINT_DELAY_COMPLETE 位于 src/backend/access/transam/xlog.c:7228，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:115。探针覆盖的操作是：等待后端解除对检查点完成的阻塞。CheckpointDelayComplete 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/CheckpointDelayComplete 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'CheckpointDelayComplete'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'CheckpointDelayComplete'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

11 - IPC: CheckpointDelayStart

等待后端解除对检查点启动的阻塞。
PostgreSQL 等待事件档案
类别IPC 事件CheckpointDelayStart 版本PG 17-18 证据2 个源码位置

官方描述译文

等待后端解除对检查点启动的阻塞。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

触发机制

WAIT_EVENT_CHECKPOINT_DELAY_START 位于 src/backend/access/transam/xlog.c:7211，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:116。探针覆盖的操作是：等待后端解除对检查点启动的阻塞。CheckpointDelayStart 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/CheckpointDelayStart 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'CheckpointDelayStart'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'CheckpointDelayStart'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

12 - IPC: CheckpointDone

等待检查点完成。
PostgreSQL 等待事件档案
类别IPC 事件CheckpointDone 版本PG 13-18 证据2 个源码位置

官方描述译文

等待检查点完成。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_CHECKPOINT_DONE 位于 src/backend/postmaster/checkpointer.c:1121，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:117。探针覆盖的操作是：等待检查点完成。CheckpointDone 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/CheckpointDone 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'CheckpointDone'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'CheckpointDone'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

13 - IPC: CheckpointStart

等待检查点启动。
PostgreSQL 等待事件档案
类别IPC 事件CheckpointStart 版本PG 13-18 证据2 个源码位置

官方描述译文

等待检查点启动。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_CHECKPOINT_START 位于 src/backend/postmaster/checkpointer.c:1100，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:118。探针覆盖的操作是：等待检查点启动。CheckpointStart 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/CheckpointStart 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'CheckpointStart'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'CheckpointStart'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

14 - IPC: ExecuteGather

等待执行 Gather 计划节点时来自子进程的活动。
PostgreSQL 等待事件档案
类别IPC 事件ExecuteGather 版本PG 13-18 证据2 个源码位置

官方描述译文

等待执行 Gather 计划节点时来自子进程的活动。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_EXECUTE_GATHER 位于 src/backend/executor/nodeGather.c:386，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:119。探针覆盖的操作是：等待执行 Gather 计划节点时来自子进程的活动。ExecuteGather 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/ExecuteGather 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'ExecuteGather'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'ExecuteGather'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

15 - IPC: HashBatchAllocate

等待被选出的 Parallel Hash 参与者分配哈希表。
PostgreSQL 等待事件档案
类别IPC 事件HashBatchAllocate 版本PG 13-18 证据2 个源码位置

官方描述译文

等待被选出的 Parallel Hash 参与者分配哈希表。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_HASH_BATCH_ALLOCATE 位于 src/backend/executor/nodeHashjoin.c:1321，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:120。探针覆盖的操作是：等待被选出的 Parallel Hash 参与者分配哈希表。HashBatchAllocate 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/HashBatchAllocate 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'HashBatchAllocate'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'HashBatchAllocate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

16 - IPC: HashBatchElect

等待选出一个负责分配哈希表的 Parallel Hash 参与者。
PostgreSQL 等待事件档案
类别IPC 事件HashBatchElect 版本PG 13-18 证据2 个源码位置

官方描述译文

等待选出一个负责分配哈希表的 Parallel Hash 参与者。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_HASH_BATCH_ELECT 位于 src/backend/executor/nodeHashjoin.c:1314，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:121。探针覆盖的操作是：等待选出一个负责分配哈希表的 Parallel Hash 参与者。HashBatchElect 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/HashBatchElect 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'HashBatchElect'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'HashBatchElect'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

17 - IPC: HashBatchLoad

等待其他 Parallel Hash 参与者完成哈希表加载。
PostgreSQL 等待事件档案
类别IPC 事件HashBatchLoad 版本PG 13-18 证据2 个源码位置

官方描述译文

等待其他 Parallel Hash 参与者完成哈希表加载。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_HASH_BATCH_LOAD 位于 src/backend/executor/nodeHashjoin.c:1341，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:122。探针覆盖的操作是：等待其他 Parallel Hash 参与者完成哈希表加载。HashBatchLoad 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/HashBatchLoad 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'HashBatchLoad'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'HashBatchLoad'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

18 - IPC: HashBuildAllocate

等待被选出的 Parallel Hash 参与者分配初始哈希表。
PostgreSQL 等待事件档案
类别IPC 事件HashBuildAllocate 版本PG 13-18 证据2 个源码位置

官方描述译文

等待被选出的 Parallel Hash 参与者分配初始哈希表。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_HASH_BUILD_ALLOCATE 位于 src/backend/executor/nodeHash.c:261，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:123。探针覆盖的操作是：等待被选出的 Parallel Hash 参与者分配初始哈希表。HashBuildAllocate 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/HashBuildAllocate 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'HashBuildAllocate'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'HashBuildAllocate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

19 - IPC: HashBuildElect

等待选出一个负责分配初始哈希表的 Parallel Hash 参与者。
PostgreSQL 等待事件档案
类别IPC 事件HashBuildElect 版本PG 13-18 证据2 个源码位置

官方描述译文

等待选出一个负责分配初始哈希表的 Parallel Hash 参与者。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_HASH_BUILD_ELECT 位于 src/backend/executor/nodeHash.c:598，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:124。探针覆盖的操作是：等待选出一个负责分配初始哈希表的 Parallel Hash 参与者。HashBuildElect 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/HashBuildElect 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'HashBuildElect'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'HashBuildElect'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

20 - IPC: HashBuildHashInner

等待其他 Parallel Hash 参与者完成对 inner relation 的哈希处理。
PostgreSQL 等待事件档案
类别IPC 事件HashBuildHashInner 版本PG 13-18 证据2 个源码位置

官方描述译文

等待其他 Parallel Hash 参与者完成对 inner relation 的哈希处理。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_HASH_BUILD_HASH_INNER 位于 src/backend/executor/nodeHash.c:324，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:125。探针覆盖的操作是：等待其他 Parallel Hash 参与者完成对 inner relation 的哈希处理。HashBuildHashInner 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/HashBuildHashInner 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'HashBuildHashInner'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'HashBuildHashInner'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

21 - IPC: HashBuildHashOuter

等待其他 Parallel Hash 参与者完成对 outer relation 的分区。
PostgreSQL 等待事件档案
类别IPC 事件HashBuildHashOuter 版本PG 13-18 证据2 个源码位置

官方描述译文

等待其他 Parallel Hash 参与者完成对 outer relation 的分区。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_HASH_BUILD_HASH_OUTER 位于 src/backend/executor/nodeHashjoin.c:397，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:126。探针覆盖的操作是：等待其他 Parallel Hash 参与者完成对 outer relation 的分区。HashBuildHashOuter 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/HashBuildHashOuter 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'HashBuildHashOuter'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'HashBuildHashOuter'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

22 - IPC: HashGrowBatchesDecide

等待选出一个 Parallel Hash 参与者，以决定后续 batch 扩容。
PostgreSQL 等待事件档案
类别IPC 事件HashGrowBatchesDecide 版本PG 13-18 证据2 个源码位置

官方描述译文

等待选出一个 Parallel Hash 参与者，以决定后续 batch 扩容。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_HASH_GROW_BATCHES_DECIDE 位于 src/backend/executor/nodeHash.c:1363，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:127。探针覆盖的操作是：等待选出一个 Parallel Hash 参与者，以决定后续 batch 扩容。HashGrowBatchesDecide 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/HashGrowBatchesDecide 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'HashGrowBatchesDecide'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'HashGrowBatchesDecide'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

23 - IPC: HashGrowBatchesElect

等待选出一个负责分配更多 batch 的 Parallel Hash 参与者。
PostgreSQL 等待事件档案
类别IPC 事件HashGrowBatchesElect 版本PG 13-18 证据2 个源码位置

官方描述译文

等待选出一个负责分配更多 batch 的 Parallel Hash 参与者。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_HASH_GROW_BATCHES_ELECT 位于 src/backend/executor/nodeHash.c:1220，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:128。探针覆盖的操作是：等待选出一个负责分配更多 batch 的 Parallel Hash 参与者。HashGrowBatchesElect 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/HashGrowBatchesElect 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'HashGrowBatchesElect'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'HashGrowBatchesElect'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

24 - IPC: HashGrowBatchesFinish

等待被选出的 Parallel Hash 参与者决定后续 batch 扩容。
PostgreSQL 等待事件档案
类别IPC 事件HashGrowBatchesFinish 版本PG 13-18 证据2 个源码位置

官方描述译文

等待被选出的 Parallel Hash 参与者决定后续 batch 扩容。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_HASH_GROW_BATCHES_FINISH 位于 src/backend/executor/nodeHash.c:1420，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:129。探针覆盖的操作是：等待被选出的 Parallel Hash 参与者决定后续 batch 扩容。HashGrowBatchesFinish 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/HashGrowBatchesFinish 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'HashGrowBatchesFinish'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'HashGrowBatchesFinish'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

25 - IPC: HashGrowBatchesReallocate

等待被选出的 Parallel Hash 参与者分配更多 batch。
PostgreSQL 等待事件档案
类别IPC 事件HashGrowBatchesReallocate 版本PG 16-18 证据4 个源码位置

官方描述译文

等待被选出的 Parallel Hash 参与者分配更多 batch。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — ✓ ✓ ✓

历史名称：IPC/HashGrowBatchesAllocate (PG 13-15)

触发机制

WAIT_EVENT_HASH_GROW_BATCHES_ALLOCATE 位于 src/backend/executor/nodeHash.c:1229，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:368。探针覆盖的操作是：等待被选出的 Parallel Hash 参与者分配更多 batch。HashGrowBatchesReallocate 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/HashGrowBatchesReallocate 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'HashGrowBatchesReallocate'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'HashGrowBatchesReallocate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

26 - IPC: HashGrowBatchesRepartition

等待其他 Parallel Hash 参与者完成重新分区。
PostgreSQL 等待事件档案
类别IPC 事件HashGrowBatchesRepartition 版本PG 13-18 证据2 个源码位置

官方描述译文

等待其他 Parallel Hash 参与者完成重新分区。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_HASH_GROW_BATCHES_REPARTITION 位于 src/backend/executor/nodeHash.c:1352，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:131。探针覆盖的操作是：等待其他 Parallel Hash 参与者完成重新分区。HashGrowBatchesRepartition 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/HashGrowBatchesRepartition 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'HashGrowBatchesRepartition'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'HashGrowBatchesRepartition'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

27 - IPC: HashGrowBucketsElect

等待选出一个负责分配更多 bucket 的 Parallel Hash 参与者。
PostgreSQL 等待事件档案
类别IPC 事件HashGrowBucketsElect 版本PG 13-18 证据2 个源码位置

官方描述译文

等待选出一个负责分配更多 bucket 的 Parallel Hash 参与者。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_HASH_GROW_BUCKETS_ELECT 位于 src/backend/executor/nodeHash.c:1669，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:132。探针覆盖的操作是：等待选出一个负责分配更多 bucket 的 Parallel Hash 参与者。HashGrowBucketsElect 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/HashGrowBucketsElect 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'HashGrowBucketsElect'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'HashGrowBucketsElect'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

28 - IPC: HashGrowBucketsReallocate

等待被选出的 Parallel Hash 参与者完成更多 bucket 的分配。
PostgreSQL 等待事件档案
类别IPC 事件HashGrowBucketsReallocate 版本PG 16-18 证据4 个源码位置

官方描述译文

等待被选出的 Parallel Hash 参与者完成更多 bucket 的分配。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — ✓ ✓ ✓

历史名称：IPC/HashGrowBucketsAllocate (PG 13-15)

触发机制

WAIT_EVENT_HASH_GROW_BUCKETS_ALLOCATE 位于 src/backend/executor/nodeHash.c:1588，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:383。探针覆盖的操作是：等待被选出的 Parallel Hash 参与者完成更多 bucket 的分配。HashGrowBucketsReallocate 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/HashGrowBucketsReallocate 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'HashGrowBucketsReallocate'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'HashGrowBucketsReallocate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

29 - IPC: HashGrowBucketsReinsert

等待其他 Parallel Hash 参与者完成将元组插入新 bucket。
PostgreSQL 等待事件档案
类别IPC 事件HashGrowBucketsReinsert 版本PG 13-18 证据2 个源码位置

官方描述译文

等待其他 Parallel Hash 参与者完成将元组插入新 bucket。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_HASH_GROW_BUCKETS_REINSERT 位于 src/backend/executor/nodeHash.c:1733，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:134。探针覆盖的操作是：等待其他 Parallel Hash 参与者完成将元组插入新 bucket。HashGrowBucketsReinsert 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/HashGrowBucketsReinsert 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'HashGrowBucketsReinsert'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'HashGrowBucketsReinsert'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

30 - IPC: LogicalApplySendData

等待逻辑复制 leader apply 进程向 parallel apply 进程发送数据。
PostgreSQL 等待事件档案
类别IPC 事件LogicalApplySendData 版本PG 16-18 证据2 个源码位置

官方描述译文

等待逻辑复制 leader apply 进程向 parallel apply 进程发送数据。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — ✓ ✓ ✓

触发机制

WAIT_EVENT_LOGICAL_APPLY_SEND_DATA 位于 src/backend/replication/logical/applyparallelworker.c:1204，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:135。探针覆盖的操作是：等待逻辑复制 leader apply 进程向 parallel apply 进程发送数据。LogicalApplySendData 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/LogicalApplySendData 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'LogicalApplySendData'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'LogicalApplySendData'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

31 - IPC: LogicalParallelApplyStateChange

等待逻辑复制 parallel apply 进程改变状态。
PostgreSQL 等待事件档案
类别IPC 事件LogicalParallelApplyStateChange 版本PG 16-18 证据2 个源码位置

官方描述译文

等待逻辑复制 parallel apply 进程改变状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — ✓ ✓ ✓

触发机制

WAIT_EVENT_LOGICAL_PARALLEL_APPLY_STATE_CHANGE 位于 src/backend/replication/logical/applyparallelworker.c:1276，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:136。探针覆盖的操作是：等待逻辑复制 parallel apply 进程改变状态。LogicalParallelApplyStateChange 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/LogicalParallelApplyStateChange 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'LogicalParallelApplyStateChange'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'LogicalParallelApplyStateChange'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

32 - IPC: LogicalSyncData

等待逻辑复制远端服务器发送用于初始表同步的数据。
PostgreSQL 等待事件档案
类别IPC 事件LogicalSyncData 版本PG 13-18 证据2 个源码位置

官方描述译文

等待逻辑复制远端服务器发送用于初始表同步的数据。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_LOGICAL_SYNC_DATA 位于 src/backend/replication/logical/tablesync.c:807，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:137。探针覆盖的操作是：等待逻辑复制远端服务器发送用于初始表同步的数据。LogicalSyncData 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/LogicalSyncData 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'LogicalSyncData'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'LogicalSyncData'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

33 - IPC: LogicalSyncStateChange

等待逻辑复制远端服务器改变状态。
PostgreSQL 等待事件档案
类别IPC 事件LogicalSyncStateChange 版本PG 13-18 证据2 个源码位置

官方描述译文

等待逻辑复制远端服务器改变状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_LOGICAL_SYNC_STATE_CHANGE 位于 src/backend/replication/logical/tablesync.c:214，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:138。探针覆盖的操作是：等待逻辑复制远端服务器改变状态。LogicalSyncStateChange 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/LogicalSyncStateChange 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'LogicalSyncStateChange'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'LogicalSyncStateChange'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

34 - IPC: MessageQueueInternal

等待另一个进程附加到共享消息队列。
PostgreSQL 等待事件档案
类别IPC 事件MessageQueueInternal 版本PG 13-18 证据2 个源码位置

官方描述译文

等待另一个进程附加到共享消息队列。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_MESSAGE_QUEUE_INTERNAL 位于 src/backend/storage/ipc/shm_mq.c:1254，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:139。探针覆盖的操作是：等待另一个进程附加到共享消息队列。MessageQueueInternal 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/MessageQueueInternal 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'MessageQueueInternal'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'MessageQueueInternal'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

35 - IPC: MessageQueuePutMessage

等待向共享消息队列写入协议消息。
PostgreSQL 等待事件档案
类别IPC 事件MessageQueuePutMessage 版本PG 13-18 证据2 个源码位置

官方描述译文

等待向共享消息队列写入协议消息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_MESSAGE_QUEUE_PUT_MESSAGE 位于 src/backend/libpq/pqmq.c:185，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:140。探针覆盖的操作是：等待向共享消息队列写入协议消息。MessageQueuePutMessage 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/MessageQueuePutMessage 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'MessageQueuePutMessage'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'MessageQueuePutMessage'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

36 - IPC: MessageQueueReceive

等待从共享消息队列接收字节。
PostgreSQL 等待事件档案
类别IPC 事件MessageQueueReceive 版本PG 13-18 证据2 个源码位置

官方描述译文

等待从共享消息队列接收字节。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_MESSAGE_QUEUE_RECEIVE 位于 src/backend/storage/ipc/shm_mq.c:1165，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:141。探针覆盖的操作是：等待从共享消息队列接收字节。MessageQueueReceive 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/MessageQueueReceive 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'MessageQueueReceive'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'MessageQueueReceive'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

37 - IPC: MessageQueueSend

等待向共享消息队列发送字节。
PostgreSQL 等待事件档案
类别IPC 事件MessageQueueSend 版本PG 13-18 证据2 个源码位置

官方描述译文

等待向共享消息队列发送字节。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_MESSAGE_QUEUE_SEND 位于 src/backend/storage/ipc/shm_mq.c:1019，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:142。探针覆盖的操作是：等待向共享消息队列发送字节。MessageQueueSend 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/MessageQueueSend 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'MessageQueueSend'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'MessageQueueSend'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

38 - IPC: MultixactCreation

等待 multixact 创建完成。
PostgreSQL 等待事件档案
类别IPC 事件MultixactCreation 版本PG 17-18 证据1 个源码位置

官方描述译文

等待 multixact 创建完成。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

触发机制

目录中仍保留该身份，但源码审计确认在 17.8+, 18.2+ 已没有活动报告点。已知曾可触发范围：17.0-17.7, 18.0-18.1。下方定义位置作为负面证据保留；当前精确版本不会从核心代码路径发出此事件。 证据：PostgreSQL 17.8 release note、PostgreSQL 18.2 release note。

正常还是麻烦？

  • 正常: 在已审计的精确版本上，不应出现活动的核心触发。
  • 需要调查: 若监控仍显示它，应核对精确小版本、扩展来源，并确认样本是否陈旧或来自另一台服务器。

诊断 SQL

正在等待 IPC/MultixactCreation 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'MultixactCreation'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'MultixactCreation'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

39 - IPC: ParallelBitmapScan

等待并行位图扫描完成初始化。
PostgreSQL 等待事件档案
类别IPC 事件ParallelBitmapScan 版本PG 13-18 证据2 个源码位置

官方描述译文

等待并行位图扫描完成初始化。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_PARALLEL_BITMAP_SCAN 位于 src/backend/executor/nodeBitmapHeapscan.c:437，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:144。探针覆盖的操作是：等待并行位图扫描完成初始化。ParallelBitmapScan 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/ParallelBitmapScan 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'ParallelBitmapScan'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'ParallelBitmapScan'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

40 - IPC: ParallelCreateIndexScan

等待并行 CREATE INDEX 工作进程完成 heap 扫描。
PostgreSQL 等待事件档案
类别IPC 事件ParallelCreateIndexScan 版本PG 13-18 证据2 个源码位置

官方描述译文

等待并行 CREATE INDEX 工作进程完成 heap 扫描。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_PARALLEL_CREATE_INDEX_SCAN 位于 src/backend/access/brin/brin.c:2600，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:145。探针覆盖的操作是：等待并行 CREATE INDEX 工作进程完成 heap 扫描。ParallelCreateIndexScan 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/ParallelCreateIndexScan 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'ParallelCreateIndexScan'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'ParallelCreateIndexScan'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

41 - IPC: ParallelFinish

等待并行工作进程完成计算。
PostgreSQL 等待事件档案
类别IPC 事件ParallelFinish 版本PG 13-18 证据2 个源码位置

官方描述译文

等待并行工作进程完成计算。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_PARALLEL_FINISH 位于 src/backend/access/transam/parallel.c:894，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:146。探针覆盖的操作是：等待并行工作进程完成计算。ParallelFinish 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/ParallelFinish 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'ParallelFinish'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'ParallelFinish'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

42 - IPC: ProcSignalBarrier

等待所有后端处理完 barrier 事件。
PostgreSQL 等待事件档案
类别IPC 事件ProcSignalBarrier 版本PG 13-18 证据2 个源码位置

官方描述译文

等待所有后端处理完 barrier 事件。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_PROC_SIGNAL_BARRIER 位于 src/backend/storage/ipc/procsignal.c:458，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:148。探针覆盖的操作是：等待所有后端处理完 barrier 事件。ProcSignalBarrier 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/ProcSignalBarrier 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'ProcSignalBarrier'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'ProcSignalBarrier'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

43 - IPC: ProcarrayGroupUpdate

等待 group leader 在事务结束时清除事务 ID。
PostgreSQL 等待事件档案
类别IPC 事件ProcarrayGroupUpdate 版本PG 17-18 证据4 个源码位置

官方描述译文

等待 group leader 在事务结束时清除事务 ID。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

历史名称：IPC/ProcArrayGroupUpdate (PG 13-16)

触发机制

WAIT_EVENT_PROCARRAY_GROUP_UPDATE 位于 src/backend/storage/ipc/procarray.c:829，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:428。探针覆盖的操作是：等待 group leader 在事务结束时清除事务 ID。ProcarrayGroupUpdate 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/ProcarrayGroupUpdate 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'ProcarrayGroupUpdate'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'ProcarrayGroupUpdate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

44 - IPC: Promote

等待备库提升。
PostgreSQL 等待事件档案
类别IPC 事件Promote 版本PG 13-18 证据2 个源码位置

官方描述译文

等待备库提升。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_PROMOTE 位于 src/backend/access/transam/xlogfuncs.c:731，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:149。探针覆盖的操作是：等待备库提升。Promote 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/Promote 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'Promote'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'Promote'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

45 - IPC: RecoveryConflictSnapshot

等待解决与 vacuum cleanup 有关的恢复冲突。
PostgreSQL 等待事件档案
类别IPC 事件RecoveryConflictSnapshot 版本PG 13-18 证据2 个源码位置

官方描述译文

等待解决与 vacuum cleanup 有关的恢复冲突。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_RECOVERY_CONFLICT_SNAPSHOT 位于 src/backend/storage/ipc/standby.c:493，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:150。探针覆盖的操作是：等待解决与 vacuum cleanup 有关的恢复冲突。RecoveryConflictSnapshot 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/RecoveryConflictSnapshot 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'RecoveryConflictSnapshot'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'RecoveryConflictSnapshot'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

46 - IPC: RecoveryConflictTablespace

等待解决与删除表空间有关的恢复冲突。
PostgreSQL 等待事件档案
类别IPC 事件RecoveryConflictTablespace 版本PG 13-18 证据2 个源码位置

官方描述译文

等待解决与删除表空间有关的恢复冲突。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_RECOVERY_CONFLICT_TABLESPACE 位于 src/backend/storage/ipc/standby.c:564，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:151。探针覆盖的操作是：等待解决与删除表空间有关的恢复冲突。RecoveryConflictTablespace 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/RecoveryConflictTablespace 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'RecoveryConflictTablespace'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'RecoveryConflictTablespace'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

47 - IPC: RecoveryEndCommand

等待 recovery_end_command 完成。
PostgreSQL 等待事件档案
类别IPC 事件RecoveryEndCommand 版本PG 15-18 证据2 个源码位置

官方描述译文

等待 recovery_end_command 完成。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_RECOVERY_END_COMMAND 位于 src/backend/access/transam/xlog.c:5337，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:152。探针覆盖的操作是：等待 recovery_end_command 完成。RecoveryEndCommand 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/RecoveryEndCommand 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'RecoveryEndCommand'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'RecoveryEndCommand'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

48 - IPC: RecoveryPause

等待恢复操作继续执行。
PostgreSQL 等待事件档案
类别IPC 事件RecoveryPause 版本PG 13-18 证据2 个源码位置

官方描述译文

等待恢复操作继续执行。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_RECOVERY_PAUSE 位于 src/backend/access/transam/xlogrecovery.c:2994，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:153。探针覆盖的操作是：等待恢复操作继续执行。RecoveryPause 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/RecoveryPause 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'RecoveryPause'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'RecoveryPause'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

49 - IPC: ReplicationOriginDrop

等待复制源变为非活动状态，以便将其删除。
PostgreSQL 等待事件档案
类别IPC 事件ReplicationOriginDrop 版本PG 13-18 证据2 个源码位置

官方描述译文

等待复制源变为非活动状态，以便将其删除。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_REPLICATION_ORIGIN_DROP 位于 src/backend/replication/logical/origin.c:408，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:154。探针覆盖的操作是：等待复制源变为非活动状态，以便将其删除。ReplicationOriginDrop 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/ReplicationOriginDrop 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'ReplicationOriginDrop'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'ReplicationOriginDrop'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

50 - IPC: ReplicationSlotDrop

等待复制槽变为非活动状态，以便将其删除。
PostgreSQL 等待事件档案
类别IPC 事件ReplicationSlotDrop 版本PG 13-18 证据2 个源码位置

官方描述译文

等待复制槽变为非活动状态，以便将其删除。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_REPLICATION_SLOT_DROP 位于 src/backend/replication/slot.c:657，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:155。探针覆盖的操作是：等待复制槽变为非活动状态，以便将其删除。ReplicationSlotDrop 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/ReplicationSlotDrop 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'ReplicationSlotDrop'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'ReplicationSlotDrop'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

51 - IPC: RestoreCommand

等待 restore_command 完成。
PostgreSQL 等待事件档案
类别IPC 事件RestoreCommand 版本PG 15-18 证据2 个源码位置

官方描述译文

等待 restore_command 完成。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_RESTORE_COMMAND 位于 src/backend/access/transam/xlogarchive.c:162，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:156。探针覆盖的操作是：等待 restore_command 完成。RestoreCommand 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/RestoreCommand 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'RestoreCommand'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'RestoreCommand'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

52 - IPC: SafeSnapshot

等待为 READ ONLY DEFERRABLE 事务获取有效 snapshot。
PostgreSQL 等待事件档案
类别IPC 事件SafeSnapshot 版本PG 13-18 证据2 个源码位置

官方描述译文

等待为 READ ONLY DEFERRABLE 事务获取有效 snapshot。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_SAFE_SNAPSHOT 位于 src/backend/storage/lmgr/predicate.c:1589，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:157。探针覆盖的操作是：等待为 READ ONLY DEFERRABLE 事务获取有效 snapshot。SafeSnapshot 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/SafeSnapshot 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'SafeSnapshot'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'SafeSnapshot'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

53 - IPC: SyncRep

等待同步复制期间来自远端服务器的确认。
PostgreSQL 等待事件档案
类别IPC 事件SyncRep 版本PG 13-18 证据2 个源码位置

官方描述译文

等待同步复制期间来自远端服务器的确认。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_SYNC_REP 位于 src/backend/replication/syncrep.c:332，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:158。探针覆盖的操作是：等待同步复制期间来自远端服务器的确认。SyncRep 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/SyncRep 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'SyncRep'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'SyncRep'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

54 - IPC: WalReceiverExit

等待 WAL receiver 退出。
PostgreSQL 等待事件档案
类别IPC 事件WalReceiverExit 版本PG 14-18 证据2 个源码位置

官方描述译文

等待 WAL receiver 退出。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_WAL_RECEIVER_EXIT 位于 src/backend/replication/walreceiverfuncs.c:228，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:159。探针覆盖的操作是：等待 WAL receiver 退出。WalReceiverExit 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/WalReceiverExit 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'WalReceiverExit'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'WalReceiverExit'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

55 - IPC: WalReceiverUpstreamCatchup

等待上游服务器的 WAL flush 位置追上请求的起始点。
PostgreSQL 等待事件档案
类别IPC 事件WalReceiverUpstreamCatchup 版本PG 17-18 证据2 个源码位置

官方描述译文

等待上游服务器的 WAL flush 位置追上请求的起始点。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓
重要

小版本可用性: 实测从 17.11+ 与 18.6+ 出现；17.10 与 18.4 中不存在，因此不能只写大版本范围。

触发机制

WAIT_EVENT_WAL_RECEIVER_UPSTREAM_CATCHUP 位于 src/backend/replication/walreceiver.c:398，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:165。探针覆盖的操作是：等待上游服务器的 WAL flush 位置追上请求的起始点。WalReceiverUpstreamCatchup 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/WalReceiverUpstreamCatchup 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'WalReceiverUpstreamCatchup'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'WalReceiverUpstreamCatchup'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

56 - IPC: WalReceiverWaitStart

等待 startup 进程发送流复制的初始数据。
PostgreSQL 等待事件档案
类别IPC 事件WalReceiverWaitStart 版本PG 14-18 证据4 个源码位置

官方描述译文

等待 startup 进程发送流复制的初始数据。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— ✓ ✓ ✓ ✓ ✓

历史名称：Client/WalReceiverWaitStart (PG 13)

触发机制

WAIT_EVENT_WAL_RECEIVER_WAIT_START 位于 src/backend/postmaster/pgstat.c:3738，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/postmaster/pgstat.c:3739。探针覆盖的操作是：等待 startup 进程发送流复制的初始数据。WalReceiverWaitStart 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/WalReceiverWaitStart 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'WalReceiverWaitStart'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'WalReceiverWaitStart'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

57 - IPC: WalSummaryReady

等待生成新的 WAL summary。
PostgreSQL 等待事件档案
类别IPC 事件WalSummaryReady 版本PG 17-18 证据2 个源码位置

官方描述译文

等待生成新的 WAL summary。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

触发机制

WAIT_EVENT_WAL_SUMMARY_READY 位于 src/backend/postmaster/walsummarizer.c:821，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:161。探针覆盖的操作是：等待生成新的 WAL summary。WalSummaryReady 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/WalSummaryReady 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'WalSummaryReady'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'WalSummaryReady'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号

58 - IPC: XactGroupUpdate

等待 group leader 在事务结束时更新事务状态。
PostgreSQL 等待事件档案
类别IPC 事件XactGroupUpdate 版本PG 13-18 证据2 个源码位置

官方描述译文

等待 group leader 在事务结束时更新事务状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WAIT_EVENT_XACT_GROUP_UPDATE 位于 src/backend/access/transam/clog.c:535，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:162。探针覆盖的操作是：等待 group leader 在事务结束时更新事务状态。XactGroupUpdate 路径已经到达进程协调点，会休眠到对端、worker、屏障、队列或复制阶段发出进展信号。

正常还是麻烦？

  • 正常: 只要所有参与者都在继续推进，短暂汇合就属正常。
  • 需要调查: 同一阶段连续三次采样仍存在、预期对端缺失或被阻塞，或队列及其依赖者停止推进时，应当调查。

诊断 SQL

正在等待 IPC/XactGroupUpdate 的会话 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
  AND wait_event = 'XactGroupUpdate'
ORDER BY query_age DESC NULLS LAST;
当前 IPC 等待分布 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'IPC'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'IPC'
  AND a.wait_event = 'XactGroupUpdate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认事件所指的对端或阶段。
  2. 检查该参与者的等待、错误与进展状态。
  3. 修复停滞的参与者或上游依赖，不要把等待者当作根因。

源码证据

关联控制项与信号