IPC waits

• 1: IPC: AppendReady
• 2: IPC: ArchiveCleanupCommand
• 3: IPC: ArchiveCommand
• 4: IPC: BackendTermination
• 5: IPC: BackupWaitWalArchive
• 6: IPC: BgworkerShutdown
• 7: IPC: BgworkerStartup
• 8: IPC: BtreePage
• 9: IPC: BufferIo
• 10: IPC: CheckpointDelayComplete
• 11: IPC: CheckpointDelayStart
• 12: IPC: CheckpointDone
• 13: IPC: CheckpointStart
• 14: IPC: ExecuteGather
• 15: IPC: HashBatchAllocate
• 16: IPC: HashBatchElect
• 17: IPC: HashBatchLoad
• 18: IPC: HashBuildAllocate
• 19: IPC: HashBuildElect
• 20: IPC: HashBuildHashInner
• 21: IPC: HashBuildHashOuter
• 22: IPC: HashGrowBatchesDecide
• 23: IPC: HashGrowBatchesElect
• 24: IPC: HashGrowBatchesFinish
• 25: IPC: HashGrowBatchesReallocate
• 26: IPC: HashGrowBatchesRepartition
• 27: IPC: HashGrowBucketsElect
• 28: IPC: HashGrowBucketsReallocate
• 29: IPC: HashGrowBucketsReinsert
• 30: IPC: LogicalApplySendData
• 31: IPC: LogicalParallelApplyStateChange
• 32: IPC: LogicalSyncData
• 33: IPC: LogicalSyncStateChange
• 34: IPC: MessageQueueInternal
• 35: IPC: MessageQueuePutMessage
• 36: IPC: MessageQueueReceive
• 37: IPC: MessageQueueSend
• 38: IPC: MultixactCreation
• 39: IPC: ParallelBitmapScan
• 40: IPC: ParallelCreateIndexScan
• 41: IPC: ParallelFinish
• 42: IPC: ProcSignalBarrier
• 43: IPC: ProcarrayGroupUpdate
• 44: IPC: Promote
• 45: IPC: RecoveryConflictSnapshot
• 46: IPC: RecoveryConflictTablespace
• 47: IPC: RecoveryEndCommand
• 48: IPC: RecoveryPause
• 49: IPC: ReplicationOriginDrop
• 50: IPC: ReplicationSlotDrop
• 51: IPC: RestoreCommand
• 52: IPC: SafeSnapshot
• 53: IPC: SyncRep
• 54: IPC: WalReceiverExit
• 55: IPC: WalReceiverUpstreamCatchup
• 56: IPC: WalReceiverWaitStart
• 57: IPC: WalSummaryReady
• 58: IPC: XactGroupUpdate

1 - IPC: AppendReady

Official description

Waiting for subplan nodes of an Append plan node to be ready

Trigger mechanism

WAIT_EVENT_APPEND_READY at src/backend/executor/nodeAppend.c:1079 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:106. The instrumented operation is: Waiting for subplan nodes of an Append plan node to be ready. The AppendReady path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

• Normal: Brief rendezvous is normal when every participant continues to advance.
• Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

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;

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;

Response

1. Identify the peer or phase named by the event.
2. Inspect that participant’s wait, error, and progress state.
3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

• PostgreSQL 18.6 · src/backend/executor/nodeAppend.c:1079 — WAIT_EVENT_APPEND_READY
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:106 — APPEND_READY

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

2 - IPC: ArchiveCleanupCommand

Official description

Waiting for archive_cleanup_command to complete

Trigger mechanism

WAIT_EVENT_ARCHIVE_CLEANUP_COMMAND at src/backend/access/transam/xlog.c:7885 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:107. The instrumented operation is: Waiting for archive_cleanup_command to complete. The ArchiveCleanupCommand path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

• Normal: Brief rendezvous is normal when every participant continues to advance.
• Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

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;

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;

Response

1. Identify the peer or phase named by the event.
2. Inspect that participant’s wait, error, and progress state.
3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

• PostgreSQL 18.6 · src/backend/access/transam/xlog.c:7885 — WAIT_EVENT_ARCHIVE_CLEANUP_COMMAND
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:107 — ARCHIVE_CLEANUP_COMMAND

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

3 - IPC: ArchiveCommand

Official description

Waiting for archive_command to complete

Trigger mechanism

WAIT_EVENT_ARCHIVE_COMMAND at src/backend/archive/shell_archive.c:79 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:108. The instrumented operation is: Waiting for archive_command to complete. The ArchiveCommand path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

• Normal: Brief rendezvous is normal when every participant continues to advance.
• Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

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;

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;

Response

1. Identify the peer or phase named by the event.
2. Inspect that participant’s wait, error, and progress state.
3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

• PostgreSQL 18.6 · src/backend/archive/shell_archive.c:79 — WAIT_EVENT_ARCHIVE_COMMAND
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:108 — ARCHIVE_COMMAND

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

4 - IPC: BackendTermination

Official description

Waiting for the termination of another backend

Trigger mechanism

WAIT_EVENT_BACKEND_TERMINATION at src/backend/storage/ipc/signalfuncs.c:210 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:109. The instrumented operation is: Waiting for the termination of another backend. The BackendTermination path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

• Normal: Brief rendezvous is normal when every participant continues to advance.
• Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

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;

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;

Response

1. Identify the peer or phase named by the event.
2. Inspect that participant’s wait, error, and progress state.
3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

• PostgreSQL 18.6 · src/backend/storage/ipc/signalfuncs.c:210 — WAIT_EVENT_BACKEND_TERMINATION
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:109 — BACKEND_TERMINATION

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

5 - IPC: BackupWaitWalArchive

Official description

Waiting for WAL files required for a backup to be successfully archived

Trigger mechanism

WAIT_EVENT_BACKUP_WAIT_WAL_ARCHIVE at src/backend/access/transam/xlog.c:9405 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:110. The instrumented operation is: Waiting for WAL files required for a backup to be successfully archived. The BackupWaitWalArchive path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

• Normal: Brief rendezvous is normal when every participant continues to advance.
• Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

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;

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;

Response

1. Identify the peer or phase named by the event.
2. Inspect that participant’s wait, error, and progress state.
3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

• PostgreSQL 18.6 · src/backend/access/transam/xlog.c:9405 — WAIT_EVENT_BACKUP_WAIT_WAL_ARCHIVE
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:110 — BACKUP_WAIT_WAL_ARCHIVE

Related controls and signals

• GUCs: [guc:wal_buffers] · [guc:synchronous_commit]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:wal_bytes] · [metric:wal_write_time]

6 - IPC: BgworkerShutdown

Official description

Waiting for background worker to shut down

Earlier names: IPC/BgWorkerShutdown (PG 13-16)

Trigger mechanism

WAIT_EVENT_BGWORKER_SHUTDOWN at src/backend/postmaster/bgworker.c:1188 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:329. The instrumented operation is: Waiting for background worker to shut down. The BgworkerShutdown path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

• Normal: Brief rendezvous is normal when every participant continues to advance.
• Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

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;

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;

Response

1. Identify the peer or phase named by the event.
2. Inspect that participant’s wait, error, and progress state.
3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

• PostgreSQL 16.15 · src/backend/postmaster/bgworker.c:1188 — WAIT_EVENT_BGWORKER_SHUTDOWN
• PostgreSQL 16.15 · src/backend/utils/activity/wait_event.c:329 — BgWorkerShutdown
• PostgreSQL 18.6 · src/backend/postmaster/bgworker.c:1275 — WAIT_EVENT_BGWORKER_SHUTDOWN
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:111 — BGWORKER_SHUTDOWN

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

7 - IPC: BgworkerStartup

Official description

Waiting for background worker to start up

Earlier names: IPC/BgWorkerStartup (PG 13-16)

Trigger mechanism

WAIT_EVENT_BGWORKER_STARTUP at src/backend/access/transam/parallel.c:771 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:332. The instrumented operation is: Waiting for background worker to start up. The BgworkerStartup path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

• Normal: Brief rendezvous is normal when every participant continues to advance.
• Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

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;

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;

Response

1. Identify the peer or phase named by the event.
2. Inspect that participant’s wait, error, and progress state.
3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

• PostgreSQL 16.15 · src/backend/access/transam/parallel.c:771 — WAIT_EVENT_BGWORKER_STARTUP
• PostgreSQL 16.15 · src/backend/utils/activity/wait_event.c:332 — BgWorkerStartup
• PostgreSQL 18.6 · src/backend/access/transam/parallel.c:775 — WAIT_EVENT_BGWORKER_STARTUP
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:112 — BGWORKER_STARTUP

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

8 - IPC: BtreePage

Official description

Waiting for the page number needed to continue a parallel B-tree scan to become available

Trigger mechanism

WAIT_EVENT_BTREE_PAGE at src/backend/access/nbtree/nbtree.c:927 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:113. The instrumented operation is: Waiting for the page number needed to continue a parallel B-tree scan to become available. The BtreePage path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

• Normal: Brief rendezvous is normal when every participant continues to advance.
• Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

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;

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;

Response

1. Identify the peer or phase named by the event.
2. Inspect that participant’s wait, error, and progress state.
3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

• PostgreSQL 18.6 · src/backend/access/nbtree/nbtree.c:927 — WAIT_EVENT_BTREE_PAGE
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:113 — BTREE_PAGE

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

9 - IPC: BufferIo

Official description

Waiting for buffer I/O to complete

Earlier names: IPC/BufferIO (PG 14-16), LWLock/BufferIO (PG 13)

Trigger mechanism

pgstat_report_wait_start at src/backend/storage/lmgr/lwlock.c:765 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/access/transam/xact.c:2627. The instrumented operation is: Waiting for buffer I/O to complete. The BufferIo path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

• Normal: Brief rendezvous is normal when every participant continues to advance.
• Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

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;

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;

Response

1. Identify the peer or phase named by the event.
2. Inspect that participant’s wait, error, and progress state.
3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

• PostgreSQL 13.23 · src/backend/access/transam/xact.c:2627 — BufferIO
• PostgreSQL 13.23 · src/backend/storage/lmgr/lwlock.c:150 — BufferIO
• PostgreSQL 13.23 · src/backend/storage/lmgr/lwlock.c:765 — pgstat_report_wait_start
• PostgreSQL 16.15 · src/backend/storage/buffer/bufmgr.c:5167 — WAIT_EVENT_BUFFER_IO

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]

10 - IPC: CheckpointDelayComplete

Official description

Waiting for a backend that blocks a checkpoint from completing

Trigger mechanism

WAIT_EVENT_CHECKPOINT_DELAY_COMPLETE at src/backend/access/transam/xlog.c:7228 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:115. The instrumented operation is: Waiting for a backend that blocks a checkpoint from completing. The CheckpointDelayComplete path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

• Normal: Brief rendezvous is normal when every participant continues to advance.
• Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

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;

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;

Response

1. Identify the peer or phase named by the event.
2. Inspect that participant’s wait, error, and progress state.
3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

• PostgreSQL 18.6 · src/backend/access/transam/xlog.c:7228 — WAIT_EVENT_CHECKPOINT_DELAY_COMPLETE
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:115 — CHECKPOINT_DELAY_COMPLETE

Related controls and signals

• GUCs: [guc:checkpoint_timeout] · [guc:max_wal_size]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:checkpoint_time]

11 - IPC: CheckpointDelayStart

Official description

Waiting for a backend that blocks a checkpoint from starting

Trigger mechanism

WAIT_EVENT_CHECKPOINT_DELAY_START at src/backend/access/transam/xlog.c:7211 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:116. The instrumented operation is: Waiting for a backend that blocks a checkpoint from starting. The CheckpointDelayStart path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

• Normal: Brief rendezvous is normal when every participant continues to advance.
• Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

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;

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;

Response

1. Identify the peer or phase named by the event.
2. Inspect that participant’s wait, error, and progress state.
3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

• PostgreSQL 18.6 · src/backend/access/transam/xlog.c:7211 — WAIT_EVENT_CHECKPOINT_DELAY_START
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:116 — CHECKPOINT_DELAY_START

Related controls and signals

• GUCs: [guc:checkpoint_timeout] · [guc:max_wal_size]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:checkpoint_time]

12 - IPC: CheckpointDone

Official description

Waiting for a checkpoint to complete

Trigger mechanism

WAIT_EVENT_CHECKPOINT_DONE at src/backend/postmaster/checkpointer.c:1121 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:117. The instrumented operation is: Waiting for a checkpoint to complete. The CheckpointDone path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

• Normal: Brief rendezvous is normal when every participant continues to advance.
• Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

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;

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;

Response

1. Identify the peer or phase named by the event.
2. Inspect that participant’s wait, error, and progress state.
3. Repair the stalled participant or upstream dependency instead of treating the waiter as the root cause.

Source evidence

• PostgreSQL 18.6 · src/backend/postmaster/checkpointer.c:1121 — WAIT_EVENT_CHECKPOINT_DONE
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:117 — CHECKPOINT_DONE

Related controls and signals

• GUCs: [guc:checkpoint_timeout] · [guc:max_wal_size]
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:checkpoint_time]

13 - IPC: CheckpointStart

Official description

Waiting for a checkpoint to start

Trigger mechanism

WAIT_EVENT_CHECKPOINT_START at src/backend/postmaster/checkpointer.c:1100 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:118. The instrumented operation is: Waiting for a checkpoint to start. The CheckpointStart path has reached a process-coordination point and sleeps until a peer, worker, barrier, queue, or replication phase signals progress.

Normal or trouble?

• Normal: Brief rendezvous is normal when every participant continues to advance.
• Investigate: Investigate when the same phase persists across three samples, the expected peer is absent or blocked, or a queue and its dependants stop moving.

Diagnostic SQL

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;

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;