I/O waits

• 1: IO: AioIoCompletion
• 2: IO: AioIoUringExecution
• 3: IO: AioIoUringSubmit
• 4: IO: BasebackupRead
• 5: IO: BasebackupSync
• 6: IO: BasebackupWrite
• 7: IO: BuffileRead
• 8: IO: BuffileTruncate
• 9: IO: BuffileWrite
• 10: IO: ControlFileRead
• 11: IO: ControlFileSync
• 12: IO: ControlFileSyncUpdate
• 13: IO: ControlFileWrite
• 14: IO: ControlFileWriteUpdate
• 15: IO: CopyFileCopy
• 16: IO: CopyFileRead
• 17: IO: CopyFileWrite
• 18: IO: DataFileExtend
• 19: IO: DataFileFlush
• 20: IO: DataFileImmediateSync
• 21: IO: DataFilePrefetch
• 22: IO: DataFileRead
• 23: IO: DataFileSync
• 24: IO: DataFileTruncate
• 25: IO: DataFileWrite
• 26: IO: DsmAllocate
• 27: IO: DsmFillZeroWrite
• 28: IO: LockFileAddtodatadirRead
• 29: IO: LockFileAddtodatadirSync
• 30: IO: LockFileAddtodatadirWrite
• 31: IO: LockFileCreateRead
• 32: IO: LockFileCreateSync
• 33: IO: LockFileCreateWrite
• 34: IO: LockFileRecheckdatadirRead
• 35: IO: LogicalChangesRead
• 36: IO: LogicalChangesWrite
• 37: IO: LogicalRewriteCheckpointSync
• 38: IO: LogicalRewriteMappingSync
• 39: IO: LogicalRewriteMappingWrite
• 40: IO: LogicalRewriteSync
• 41: IO: LogicalRewriteTruncate
• 42: IO: LogicalRewriteWrite
• 43: IO: LogicalSubxactRead
• 44: IO: LogicalSubxactWrite
• 45: IO: RelationMapRead
• 46: IO: RelationMapReplace
• 47: IO: RelationMapSync
• 48: IO: RelationMapWrite
• 49: IO: ReorderBufferRead
• 50: IO: ReorderBufferWrite
• 51: IO: ReorderLogicalMappingRead
• 52: IO: ReplicationSlotRead
• 53: IO: ReplicationSlotRestoreSync
• 54: IO: ReplicationSlotSync
• 55: IO: ReplicationSlotWrite
• 56: IO: SlruFlushSync
• 57: IO: SlruRead
• 58: IO: SlruSync
• 59: IO: SlruWrite
• 60: IO: SnapbuildRead
• 61: IO: SnapbuildSync
• 62: IO: SnapbuildWrite
• 63: IO: TimelineHistoryFileSync
• 64: IO: TimelineHistoryFileWrite
• 65: IO: TimelineHistoryRead
• 66: IO: TimelineHistorySync
• 67: IO: TimelineHistoryWrite
• 68: IO: TwophaseFileRead
• 69: IO: TwophaseFileSync
• 70: IO: TwophaseFileWrite
• 71: IO: VersionFileSync
• 72: IO: VersionFileWrite
• 73: IO: WalBootstrapSync
• 74: IO: WalBootstrapWrite
• 75: IO: WalCopyRead
• 76: IO: WalCopySync
• 77: IO: WalCopyWrite
• 78: IO: WalInitSync
• 79: IO: WalInitWrite
• 80: IO: WalRead
• 81: IO: WalSummaryRead
• 82: IO: WalSummaryWrite
• 83: IO: WalSync
• 84: IO: WalSyncMethodAssign
• 85: IO: WalWrite
• 86: IO: WalsenderTimelineHistoryRead

SELECT backend_type, object, context,
       reads, read_time, writes, write_time,
       writebacks, fsyncs, fsync_time
FROM pg_stat_io
ORDER BY coalesce(read_time, 0) + coalesce(write_time, 0) + coalesce(fsync_time, 0) DESC;

1 - IO: AioIoCompletion

Official description

Waiting for another process to complete IO

Trigger mechanism

WAIT_EVENT_AIO_IO_COMPLETION at src/backend/storage/aio/aio.c:643 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:196. The instrumented operation is: Waiting for another process to complete IO. PostgreSQL reports AioIoCompletion around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

• Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
• Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

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 = 'IO'
  AND wait_event = 'AioIoCompletion'
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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'AioIoCompletion'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Confirm the workload phase should touch this file class.
2. Correlate with pg_stat_io where available and per-device latency.
3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

• PostgreSQL 18.6 · src/backend/storage/aio/aio.c:643 — WAIT_EVENT_AIO_IO_COMPLETION
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:196 — AIO_IO_COMPLETION

Related controls and signals

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

2 - IO: AioIoUringExecution

Official description

Waiting for IO execution via io_uring

Trigger mechanism

WAIT_EVENT_AIO_IO_URING_EXECUTION at src/backend/storage/aio/method_io_uring.c:624 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:198. The instrumented operation is: Waiting for IO execution via io_uring. PostgreSQL reports AioIoUringExecution around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

• Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
• Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

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 = 'IO'
  AND wait_event = 'AioIoUringExecution'
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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'AioIoUringExecution'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Confirm the workload phase should touch this file class.
2. Correlate with pg_stat_io where available and per-device latency.
3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

• PostgreSQL 18.6 · src/backend/storage/aio/method_io_uring.c:624 — WAIT_EVENT_AIO_IO_URING_EXECUTION
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:198 — AIO_IO_URING_EXECUTION

Related controls and signals

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

3 - IO: AioIoUringSubmit

Official description

Waiting for IO submission via io_uring

Trigger mechanism

WAIT_EVENT_AIO_IO_URING_SUBMIT at src/backend/storage/aio/method_io_uring.c:451 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:197. The instrumented operation is: Waiting for IO submission via io_uring. PostgreSQL reports AioIoUringSubmit around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

• Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
• Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

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 = 'IO'
  AND wait_event = 'AioIoUringSubmit'
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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'AioIoUringSubmit'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Confirm the workload phase should touch this file class.
2. Correlate with pg_stat_io where available and per-device latency.
3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

• PostgreSQL 18.6 · src/backend/storage/aio/method_io_uring.c:451 — WAIT_EVENT_AIO_IO_URING_SUBMIT
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:197 — AIO_IO_URING_SUBMIT

Related controls and signals

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

4 - IO: BasebackupRead

Official description

Waiting for base backup to read from a file

Earlier names: IO/BaseBackupRead (PG 14-16)

Trigger mechanism

WAIT_EVENT_BASEBACKUP_READ at src/backend/backup/basebackup.c:1837 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:541. The instrumented operation is: Waiting for base backup to read from a file. PostgreSQL reports BasebackupRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

• Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
• Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

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 = 'IO'
  AND wait_event = 'BasebackupRead'
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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'BasebackupRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Confirm the workload phase should touch this file class.
2. Correlate with pg_stat_io where available and per-device latency.
3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

• PostgreSQL 16.15 · src/backend/backup/basebackup.c:1837 — WAIT_EVENT_BASEBACKUP_READ
• PostgreSQL 16.15 · src/backend/utils/activity/wait_event.c:541 — BaseBackupRead
• PostgreSQL 18.6 · src/backend/backup/basebackup.c:2119 — WAIT_EVENT_BASEBACKUP_READ
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:199 — BASEBACKUP_READ

Related controls and signals

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

5 - IO: BasebackupSync

Official description

Waiting for data written by a base backup to reach durable storage

Earlier names: IO/BaseBackupSync (PG 15-16)

Trigger mechanism

WAIT_EVENT_BASEBACKUP_SYNC at src/backend/backup/basebackup_server.c:206 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:544. The instrumented operation is: Waiting for data written by a base backup to reach durable storage. PostgreSQL reports BasebackupSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

• Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
• Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

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 = 'IO'
  AND wait_event = 'BasebackupSync'
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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'BasebackupSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Confirm the workload phase should touch this file class.
2. Correlate with pg_stat_io where available and per-device latency.
3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

• PostgreSQL 16.15 · src/backend/backup/basebackup_server.c:206 — WAIT_EVENT_BASEBACKUP_SYNC
• PostgreSQL 16.15 · src/backend/utils/activity/wait_event.c:544 — BaseBackupSync
• PostgreSQL 18.6 · src/backend/backup/basebackup_server.c:204 — WAIT_EVENT_BASEBACKUP_SYNC
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:200 — BASEBACKUP_SYNC

Related controls and signals

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

6 - IO: BasebackupWrite

Official description

Waiting for base backup to write to a file

Earlier names: IO/BaseBackupWrite (PG 15-16)

Trigger mechanism

WAIT_EVENT_BASEBACKUP_WRITE at src/backend/backup/basebackup_server.c:168 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:547. The instrumented operation is: Waiting for base backup to write to a file. PostgreSQL reports BasebackupWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

• Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
• Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

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 = 'IO'
  AND wait_event = 'BasebackupWrite'
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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'BasebackupWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Confirm the workload phase should touch this file class.
2. Correlate with pg_stat_io where available and per-device latency.
3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

• PostgreSQL 16.15 · src/backend/backup/basebackup_server.c:168 — WAIT_EVENT_BASEBACKUP_WRITE
• PostgreSQL 16.15 · src/backend/utils/activity/wait_event.c:547 — BaseBackupWrite
• PostgreSQL 18.6 · src/backend/backup/basebackup_server.c:166 — WAIT_EVENT_BASEBACKUP_WRITE
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:201 — BASEBACKUP_WRITE

Related controls and signals

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

7 - IO: BuffileRead

Official description

Waiting for a read from a buffered file

Earlier names: IO/BufFileRead (PG 13-16)

Trigger mechanism

WAIT_EVENT_BUFFILE_READ at src/backend/storage/file/buffile.c:464 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:550. The instrumented operation is: Waiting for a read from a buffered file. PostgreSQL reports BuffileRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

• Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
• Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

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 = 'IO'
  AND wait_event = 'BuffileRead'
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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'BuffileRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Confirm the workload phase should touch this file class.
2. Correlate with pg_stat_io where available and per-device latency.
3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

• PostgreSQL 16.15 · src/backend/storage/file/buffile.c:464 — WAIT_EVENT_BUFFILE_READ
• PostgreSQL 16.15 · src/backend/utils/activity/wait_event.c:550 — BufFileRead
• PostgreSQL 18.6 · src/backend/storage/file/buffile.c:464 — WAIT_EVENT_BUFFILE_READ
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:202 — BUFFILE_READ

Related controls and signals

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

8 - IO: BuffileTruncate

Official description

Waiting for a buffered file to be truncated

Earlier names: IO/BufFileTruncate (PG 14-16)

Trigger mechanism

WAIT_EVENT_BUFFILE_TRUNCATE at src/backend/storage/file/buffile.c:989 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:556. The instrumented operation is: Waiting for a buffered file to be truncated. PostgreSQL reports BuffileTruncate around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

• Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
• Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

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 = 'IO'
  AND wait_event = 'BuffileTruncate'
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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'BuffileTruncate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Confirm the workload phase should touch this file class.
2. Correlate with pg_stat_io where available and per-device latency.
3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

• PostgreSQL 16.15 · src/backend/storage/file/buffile.c:989 — WAIT_EVENT_BUFFILE_TRUNCATE
• PostgreSQL 16.15 · src/backend/utils/activity/wait_event.c:556 — BufFileTruncate
• PostgreSQL 18.6 · src/backend/storage/file/buffile.c:966 — WAIT_EVENT_BUFFILE_TRUNCATE
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:204 — BUFFILE_TRUNCATE

Related controls and signals

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

9 - IO: BuffileWrite

Official description

Waiting for a write to a buffered file

Earlier names: IO/BufFileWrite (PG 13-16)

Trigger mechanism

WAIT_EVENT_BUFFILE_WRITE at src/backend/storage/file/buffile.c:541 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event.c:553. The instrumented operation is: Waiting for a write to a buffered file. PostgreSQL reports BuffileWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

• Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
• Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

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 = 'IO'
  AND wait_event = 'BuffileWrite'
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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'BuffileWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Confirm the workload phase should touch this file class.
2. Correlate with pg_stat_io where available and per-device latency.
3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

• PostgreSQL 16.15 · src/backend/storage/file/buffile.c:541 — WAIT_EVENT_BUFFILE_WRITE
• PostgreSQL 16.15 · src/backend/utils/activity/wait_event.c:553 — BufFileWrite
• PostgreSQL 18.6 · src/backend/storage/file/buffile.c:541 — WAIT_EVENT_BUFFILE_WRITE
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:203 — BUFFILE_WRITE

Related controls and signals

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

10 - IO: ControlFileRead

Official description

Waiting for a read from the pg_control file

Trigger mechanism

WAIT_EVENT_CONTROL_FILE_READ at src/backend/access/transam/xlog.c:4362 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:205. The instrumented operation is: Waiting for a read from the pg_control file. PostgreSQL reports ControlFileRead around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

• Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
• Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

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 = 'IO'
  AND wait_event = 'ControlFileRead'
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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'ControlFileRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Confirm the workload phase should touch this file class.
2. Correlate with pg_stat_io where available and per-device latency.
3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

• PostgreSQL 18.6 · src/backend/access/transam/xlog.c:4362 — WAIT_EVENT_CONTROL_FILE_READ
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:205 — CONTROL_FILE_READ

Related controls and signals

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

11 - IO: ControlFileSync

Official description

Waiting for the pg_control file to reach durable storage

Trigger mechanism

WAIT_EVENT_CONTROL_FILE_SYNC at src/backend/access/transam/xlog.c:4328 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:206. The instrumented operation is: Waiting for the pg_control file to reach durable storage. PostgreSQL reports ControlFileSync around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

• Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
• Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

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 = 'IO'
  AND wait_event = 'ControlFileSync'
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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'ControlFileSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Confirm the workload phase should touch this file class.
2. Correlate with pg_stat_io where available and per-device latency.
3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

• PostgreSQL 18.6 · src/backend/access/transam/xlog.c:4328 — WAIT_EVENT_CONTROL_FILE_SYNC
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:206 — CONTROL_FILE_SYNC

Related controls and signals

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

12 - IO: ControlFileSyncUpdate

Official description

Waiting for an update to the pg_control file to reach durable storage

Trigger mechanism

WAIT_EVENT_CONTROL_FILE_SYNC_UPDATE at src/common/controldata_utils.c:259 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:207. The instrumented operation is: Waiting for an update to the pg_control file to reach durable storage. PostgreSQL reports ControlFileSyncUpdate around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

• Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
• Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

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 = 'IO'
  AND wait_event = 'ControlFileSyncUpdate'
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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'ControlFileSyncUpdate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Confirm the workload phase should touch this file class.
2. Correlate with pg_stat_io where available and per-device latency.
3. Fix the access path, burst shape, or affected storage tier before tuning unrelated memory settings.

Source evidence

• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:207 — CONTROL_FILE_SYNC_UPDATE
• PostgreSQL 18.6 · src/common/controldata_utils.c:259 — WAIT_EVENT_CONTROL_FILE_SYNC_UPDATE

Related controls and signals

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

13 - IO: ControlFileWrite

Official description

Waiting for a write to the pg_control file

Trigger mechanism

WAIT_EVENT_CONTROL_FILE_WRITE at src/backend/access/transam/xlog.c:4315 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:208. The instrumented operation is: Waiting for a write to the pg_control file. PostgreSQL reports ControlFileWrite around the instrumented file or asynchronous-I/O operation named by this event. The backend resumes after the kernel, storage stack, or I/O worker completes that step.

Normal or trouble?

• Normal: The wait is normal when the workload is expected to perform this read, write, sync, allocation, or completion operation at the observed rate.
• Investigate: Investigate when it persists with foreground latency, many concurrent waiters, storage tail latency, throttling, or errors.

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 = 'IO'
  AND wait_event = 'ControlFileWrite'
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 = 'IO'
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 = 'IO'
  AND a.wait_event = 'ControlFileWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;