跳转到主要内容

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

返回本页常规视图.

I/O 等待

文件读取、写入、同步、分配与异步 I/O 完成。

IO 表示 PostgreSQL 已为某个文件操作设置探针，而后端必须等内核或另一个 I/O worker 推进后才能继续。它指出的是哪条 PostgreSQL 文件路径，但单凭事件本身不能证明存储很慢。

把事件、操作和负载阶段一起读

名称通常同时编码对象与操作：DataFileRead、WalSync、SlruWrite、ReorderBufferRead。先问当前负载是否本来就该执行这项操作，再把持续时间与并发度关联到 pg_stat_io（PG16+）和操作系统延迟。

  • 正常： 扫描读取数据文件，检查点同步脏文件，备份读写，恢复读取 WAL。
  • 关注： 同一个前台 I/O 事件在连续样本中存在，而且设备或查询延迟上升。
  • 紧急： 大量后端排队等待 sync/write、出现错误，或受影响路径达到饱和/限速。

值得先认出的事件

事件 第一解释
DataFileRead 缓存未命中或扫描正在读取关系数据
DataFileWrite 后端/检查点路径正在写关系数据
DataFileSync 关系改动正在持久化
WalWrite 正在写入 WAL 字节
WalSync WAL 持久性边界等待 fsync/fdatasync
SlruRead 读取事务相关 SLRU 页面
BuffileRead 读取临时/溢写文件
AioIoCompletion PG18 AIO 工作尚未完成

PG16+ I/O 上下文 

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;

常见误读

  • 有意执行顺序扫描时，大量 DataFileRead 可能只是健康吞吐。
  • WalWrite 与 LWLock WALWrite 不是一回事：前者是文件操作，后者是内部协调。
  • 设备平均延迟可能掩盖单块 WAL 卷饱和或长尾延迟尖刺。
  • 增大缓存不能解决所有读取等待；糟糕计划和一次性冷扫描仍可能挤出有用页面。

1 - IO: AioIoCompletion

等待另一个进程完成 I/O。
PostgreSQL 等待事件档案
类别IO 事件AioIoCompletion 版本PG 18 证据2 个源码位置

官方描述译文

等待另一个进程完成 I/O。

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

触发机制

WAIT_EVENT_AIO_IO_COMPLETION 位于 src/backend/storage/aio/aio.c:643，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:196。探针覆盖的操作是：等待另一个进程完成 I/O。PostgreSQL 在 AioIoCompletion 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/AioIoCompletion 的会话 
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;
当前 IO 等待分布 
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;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

2 - IO: AioIoUringExecution

等待通过 io_uring 执行 I/O。
PostgreSQL 等待事件档案
类别IO 事件AioIoUringExecution 版本PG 18 证据2 个源码位置

官方描述译文

等待通过 io_uring 执行 I/O。

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

触发机制

WAIT_EVENT_AIO_IO_URING_EXECUTION 位于 src/backend/storage/aio/method_io_uring.c:624，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:198。探针覆盖的操作是：等待通过 io_uring 执行 I/O。PostgreSQL 在 AioIoUringExecution 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/AioIoUringExecution 的会话 
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;
当前 IO 等待分布 
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;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

3 - IO: AioIoUringSubmit

等待通过 io_uring 提交 I/O。
PostgreSQL 等待事件档案
类别IO 事件AioIoUringSubmit 版本PG 18 证据2 个源码位置

官方描述译文

等待通过 io_uring 提交 I/O。

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

触发机制

WAIT_EVENT_AIO_IO_URING_SUBMIT 位于 src/backend/storage/aio/method_io_uring.c:451，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:197。探针覆盖的操作是：等待通过 io_uring 提交 I/O。PostgreSQL 在 AioIoUringSubmit 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/AioIoUringSubmit 的会话 
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;
当前 IO 等待分布 
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;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

4 - IO: BasebackupRead

等待基础备份从文件中读取数据。
PostgreSQL 等待事件档案
类别IO 事件BasebackupRead 版本PG 17-18 证据4 个源码位置

官方描述译文

等待基础备份从文件中读取数据。

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

历史名称：IO/BaseBackupRead (PG 14-16)

触发机制

WAIT_EVENT_BASEBACKUP_READ 位于 src/backend/backup/basebackup.c:1837，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:541。探针覆盖的操作是：等待基础备份从文件中读取数据。PostgreSQL 在 BasebackupRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/BasebackupRead 的会话 
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;
当前 IO 等待分布 
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;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

5 - IO: BasebackupSync

等待基础备份写入的数据到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件BasebackupSync 版本PG 17-18 证据4 个源码位置

官方描述译文

等待基础备份写入的数据到达持久化存储。

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

历史名称：IO/BaseBackupSync (PG 15-16)

触发机制

WAIT_EVENT_BASEBACKUP_SYNC 位于 src/backend/backup/basebackup_server.c:206，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:544。探针覆盖的操作是：等待基础备份写入的数据到达持久化存储。PostgreSQL 在 BasebackupSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/BasebackupSync 的会话 
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;
当前 IO 等待分布 
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;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

6 - IO: BasebackupWrite

等待基础备份向文件写入数据。
PostgreSQL 等待事件档案
类别IO 事件BasebackupWrite 版本PG 17-18 证据4 个源码位置

官方描述译文

等待基础备份向文件写入数据。

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

历史名称：IO/BaseBackupWrite (PG 15-16)

触发机制

WAIT_EVENT_BASEBACKUP_WRITE 位于 src/backend/backup/basebackup_server.c:168，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:547。探针覆盖的操作是：等待基础备份向文件写入数据。PostgreSQL 在 BasebackupWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/BasebackupWrite 的会话 
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;
当前 IO 等待分布 
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;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

7 - IO: BuffileRead

等待从缓冲文件中读取数据。
PostgreSQL 等待事件档案
类别IO 事件BuffileRead 版本PG 17-18 证据4 个源码位置

官方描述译文

等待从缓冲文件中读取数据。

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

历史名称：IO/BufFileRead (PG 13-16)

触发机制

WAIT_EVENT_BUFFILE_READ 位于 src/backend/storage/file/buffile.c:464，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:550。探针覆盖的操作是：等待从缓冲文件中读取数据。PostgreSQL 在 BuffileRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/BuffileRead 的会话 
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;
当前 IO 等待分布 
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;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

8 - IO: BuffileTruncate

等待截断缓冲文件。
PostgreSQL 等待事件档案
类别IO 事件BuffileTruncate 版本PG 17-18 证据4 个源码位置

官方描述译文

等待截断缓冲文件。

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

历史名称：IO/BufFileTruncate (PG 14-16)

触发机制

WAIT_EVENT_BUFFILE_TRUNCATE 位于 src/backend/storage/file/buffile.c:989，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:556。探针覆盖的操作是：等待截断缓冲文件。PostgreSQL 在 BuffileTruncate 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/BuffileTruncate 的会话 
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;
当前 IO 等待分布 
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;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

9 - IO: BuffileWrite

等待向缓冲文件写入数据。
PostgreSQL 等待事件档案
类别IO 事件BuffileWrite 版本PG 17-18 证据4 个源码位置

官方描述译文

等待向缓冲文件写入数据。

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

历史名称：IO/BufFileWrite (PG 13-16)

触发机制

WAIT_EVENT_BUFFILE_WRITE 位于 src/backend/storage/file/buffile.c:541，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:553。探针覆盖的操作是：等待向缓冲文件写入数据。PostgreSQL 在 BuffileWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/BuffileWrite 的会话 
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;
当前 IO 等待分布 
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;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

10 - IO: ControlFileRead

等待从 pg_control 文件中读取数据。
PostgreSQL 等待事件档案
类别IO 事件ControlFileRead 版本PG 13-18 证据2 个源码位置

官方描述译文

等待从 pg_control 文件中读取数据。

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

触发机制

WAIT_EVENT_CONTROL_FILE_READ 位于 src/backend/access/transam/xlog.c:4362，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:205。探针覆盖的操作是：等待从 pg_control 文件中读取数据。PostgreSQL 在 ControlFileRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/ControlFileRead 的会话 
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;
当前 IO 等待分布 
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;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

11 - IO: ControlFileSync

等待 pg_control 文件到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件ControlFileSync 版本PG 13-18 证据2 个源码位置

官方描述译文

等待 pg_control 文件到达持久化存储。

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

触发机制

WAIT_EVENT_CONTROL_FILE_SYNC 位于 src/backend/access/transam/xlog.c:4328，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:206。探针覆盖的操作是：等待 pg_control 文件到达持久化存储。PostgreSQL 在 ControlFileSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/ControlFileSync 的会话 
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;
当前 IO 等待分布 
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;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

12 - IO: ControlFileSyncUpdate

等待 pg_control 文件的更新内容到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件ControlFileSyncUpdate 版本PG 13-18 证据2 个源码位置

官方描述译文

等待 pg_control 文件的更新内容到达持久化存储。

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

触发机制

WAIT_EVENT_CONTROL_FILE_SYNC_UPDATE 位于 src/common/controldata_utils.c:259，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:207。探针覆盖的操作是：等待 pg_control 文件的更新内容到达持久化存储。PostgreSQL 在 ControlFileSyncUpdate 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/ControlFileSyncUpdate 的会话 
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;
当前 IO 等待分布 
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;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

13 - IO: ControlFileWrite

等待向 pg_control 文件写入数据。
PostgreSQL 等待事件档案
类别IO 事件ControlFileWrite 版本PG 13-18 证据2 个源码位置

官方描述译文

等待向 pg_control 文件写入数据。

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

触发机制

WAIT_EVENT_CONTROL_FILE_WRITE 位于 src/backend/access/transam/xlog.c:4315，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:208。探针覆盖的操作是：等待向 pg_control 文件写入数据。PostgreSQL 在 ControlFileWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/ControlFileWrite 的会话 
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;
当前 IO 等待分布 
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;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

14 - IO: ControlFileWriteUpdate

等待通过写入来更新 pg_control 文件。
PostgreSQL 等待事件档案
类别IO 事件ControlFileWriteUpdate 版本PG 13-18 证据2 个源码位置

官方描述译文

等待通过写入来更新 pg_control 文件。

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

触发机制

WAIT_EVENT_CONTROL_FILE_WRITE_UPDATE 位于 src/common/controldata_utils.c:235，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:209。探针覆盖的操作是：等待通过写入来更新 pg_control 文件。PostgreSQL 在 ControlFileWriteUpdate 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/ControlFileWriteUpdate 的会话 
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 = 'ControlFileWriteUpdate'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'ControlFileWriteUpdate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

15 - IO: CopyFileCopy

等待文件复制操作完成。
PostgreSQL 等待事件档案
类别IO 事件CopyFileCopy 版本PG 18 证据2 个源码位置

官方描述译文

等待文件复制操作完成。

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

触发机制

WAIT_EVENT_COPY_FILE_COPY 位于 src/backend/storage/file/copydir.c:270，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:210。探针覆盖的操作是：等待文件复制操作完成。PostgreSQL 在 CopyFileCopy 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/CopyFileCopy 的会话 
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 = 'CopyFileCopy'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'CopyFileCopy'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

16 - IO: CopyFileRead

等待在文件复制操作期间读取数据。
PostgreSQL 等待事件档案
类别IO 事件CopyFileRead 版本PG 13-18 证据2 个源码位置

官方描述译文

等待在文件复制操作期间读取数据。

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

触发机制

WAIT_EVENT_COPY_FILE_READ 位于 src/backend/storage/file/copydir.c:195，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:211。探针覆盖的操作是：等待在文件复制操作期间读取数据。PostgreSQL 在 CopyFileRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/CopyFileRead 的会话 
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 = 'CopyFileRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'CopyFileRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

17 - IO: CopyFileWrite

等待在文件复制操作期间写入数据。
PostgreSQL 等待事件档案
类别IO 事件CopyFileWrite 版本PG 13-18 证据2 个源码位置

官方描述译文

等待在文件复制操作期间写入数据。

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

触发机制

WAIT_EVENT_COPY_FILE_WRITE 位于 src/backend/storage/file/copydir.c:205，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:212。探针覆盖的操作是：等待在文件复制操作期间写入数据。PostgreSQL 在 CopyFileWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/CopyFileWrite 的会话 
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 = 'CopyFileWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'CopyFileWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

18 - IO: DataFileExtend

等待扩展 relation 数据文件。
PostgreSQL 等待事件档案
类别IO 事件DataFileExtend 版本PG 13-18 证据2 个源码位置

官方描述译文

等待扩展 relation 数据文件。

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

触发机制

WAIT_EVENT_DATA_FILE_EXTEND 位于 src/backend/storage/smgr/md.c:512，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:213。探针覆盖的操作是：等待扩展 relation 数据文件。PostgreSQL 在 DataFileExtend 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/DataFileExtend 的会话 
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 = 'DataFileExtend'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'DataFileExtend'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

19 - IO: DataFileFlush

等待 relation 数据文件到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件DataFileFlush 版本PG 13-18 证据2 个源码位置

官方描述译文

等待 relation 数据文件到达持久化存储。

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

触发机制

WAIT_EVENT_DATA_FILE_FLUSH 位于 src/backend/storage/smgr/md.c:1208，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:214。探针覆盖的操作是：等待 relation 数据文件到达持久化存储。PostgreSQL 在 DataFileFlush 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/DataFileFlush 的会话 
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 = 'DataFileFlush'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'DataFileFlush'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

20 - IO: DataFileImmediateSync

等待将 relation 数据文件立即同步到持久化存储。
PostgreSQL 等待事件档案
类别IO 事件DataFileImmediateSync 版本PG 13-18 证据2 个源码位置

官方描述译文

等待将 relation 数据文件立即同步到持久化存储。

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

触发机制

WAIT_EVENT_DATA_FILE_IMMEDIATE_SYNC 位于 src/backend/storage/smgr/md.c:1466，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:215。探针覆盖的操作是：等待将 relation 数据文件立即同步到持久化存储。PostgreSQL 在 DataFileImmediateSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/DataFileImmediateSync 的会话 
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 = 'DataFileImmediateSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'DataFileImmediateSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

21 - IO: DataFilePrefetch

等待从 relation 数据文件异步预取数据。
PostgreSQL 等待事件档案
类别IO 事件DataFilePrefetch 版本PG 13-18 证据2 个源码位置

官方描述译文

等待从 relation 数据文件异步预取数据。

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

触发机制

WAIT_EVENT_DATA_FILE_PREFETCH 位于 src/backend/storage/smgr/md.c:767，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:216。探针覆盖的操作是：等待从 relation 数据文件异步预取数据。PostgreSQL 在 DataFilePrefetch 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/DataFilePrefetch 的会话 
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 = 'DataFilePrefetch'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'DataFilePrefetch'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

22 - IO: DataFileRead

等待从 relation 数据文件中读取数据。
PostgreSQL 等待事件档案
类别IO 事件DataFileRead 版本PG 13-18 证据2 个源码位置

官方描述译文

等待从 relation 数据文件中读取数据。

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

触发机制

WAIT_EVENT_DATA_FILE_READ 位于 src/backend/storage/aio/aio_io.c:127，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:217。探针覆盖的操作是：等待从 relation 数据文件中读取数据。PostgreSQL 在 DataFileRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/DataFileRead 的会话 
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 = 'DataFileRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'DataFileRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

23 - IO: DataFileSync

等待 relation 数据文件的变更到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件DataFileSync 版本PG 13-18 证据2 个源码位置

官方描述译文

等待 relation 数据文件的变更到达持久化存储。

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

触发机制

WAIT_EVENT_DATA_FILE_SYNC 位于 src/backend/storage/smgr/md.c:1526，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:218。探针覆盖的操作是：等待 relation 数据文件的变更到达持久化存储。PostgreSQL 在 DataFileSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/DataFileSync 的会话 
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 = 'DataFileSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'DataFileSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

24 - IO: DataFileTruncate

等待截断 relation 数据文件。
PostgreSQL 等待事件档案
类别IO 事件DataFileTruncate 版本PG 13-18 证据2 个源码位置

官方描述译文

等待截断 relation 数据文件。

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

触发机制

WAIT_EVENT_DATA_FILE_TRUNCATE 位于 src/backend/storage/smgr/md.c:1329，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:219。探针覆盖的操作是：等待截断 relation 数据文件。PostgreSQL 在 DataFileTruncate 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/DataFileTruncate 的会话 
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 = 'DataFileTruncate'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'DataFileTruncate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

25 - IO: DataFileWrite

等待向 relation 数据文件写入数据。
PostgreSQL 等待事件档案
类别IO 事件DataFileWrite 版本PG 13-18 证据2 个源码位置

官方描述译文

等待向 relation 数据文件写入数据。

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

触发机制

WAIT_EVENT_DATA_FILE_WRITE 位于 src/backend/storage/aio/aio_io.c:134，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:220。探针覆盖的操作是：等待向 relation 数据文件写入数据。PostgreSQL 在 DataFileWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/DataFileWrite 的会话 
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 = 'DataFileWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'DataFileWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

26 - IO: DsmAllocate

等待分配动态共享内存段。
PostgreSQL 等待事件档案
类别IO 事件DsmAllocate 版本PG 17-18 证据4 个源码位置

官方描述译文

等待分配动态共享内存段。

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

历史名称：IO/DSMAllocate (PG 16)

触发机制

WAIT_EVENT_DSM_ALLOCATE 位于 src/backend/storage/ipc/dsm_impl.c:366，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:604。探针覆盖的操作是：等待分配动态共享内存段。PostgreSQL 在 DsmAllocate 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/DsmAllocate 的会话 
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 = 'DsmAllocate'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'DsmAllocate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

27 - IO: DsmFillZeroWrite

等待用零值填充动态共享内存的后备文件。
PostgreSQL 等待事件档案
类别IO 事件DsmFillZeroWrite 版本PG 17-18 证据4 个源码位置

官方描述译文

等待用零值填充动态共享内存的后备文件。

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

历史名称：IO/DSMFillZeroWrite (PG 13-16)

触发机制

WAIT_EVENT_DSM_FILL_ZERO_WRITE 位于 src/backend/storage/ipc/dsm_impl.c:891，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:607。探针覆盖的操作是：等待用零值填充动态共享内存的后备文件。PostgreSQL 在 DsmFillZeroWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/DsmFillZeroWrite 的会话 
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 = 'DsmFillZeroWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'DsmFillZeroWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

28 - IO: LockFileAddtodatadirRead

等待在向数据目录锁文件添加一行时读取数据。
PostgreSQL 等待事件档案
类别IO 事件LockFileAddtodatadirRead 版本PG 17-18 证据4 个源码位置

官方描述译文

等待在向数据目录锁文件添加一行时读取数据。

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

历史名称：IO/LockFileAddToDataDirRead (PG 13-16)

触发机制

WAIT_EVENT_LOCK_FILE_ADDTODATADIR_READ 位于 src/backend/utils/init/miscinit.c:1586，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:610。探针覆盖的操作是：等待在向数据目录锁文件添加一行时读取数据。PostgreSQL 在 LockFileAddtodatadirRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/LockFileAddtodatadirRead 的会话 
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 = 'LockFileAddtodatadirRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LockFileAddtodatadirRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

29 - IO: LockFileAddtodatadirSync

等待向数据目录锁文件添加一行时写入的数据到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件LockFileAddtodatadirSync 版本PG 17-18 证据4 个源码位置

官方描述译文

等待向数据目录锁文件添加一行时写入的数据到达持久化存储。

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

历史名称：IO/LockFileAddToDataDirSync (PG 13-16)

触发机制

WAIT_EVENT_LOCK_FILE_ADDTODATADIR_SYNC 位于 src/backend/utils/init/miscinit.c:1663，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:613。探针覆盖的操作是：等待向数据目录锁文件添加一行时写入的数据到达持久化存储。PostgreSQL 在 LockFileAddtodatadirSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/LockFileAddtodatadirSync 的会话 
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 = 'LockFileAddtodatadirSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LockFileAddtodatadirSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

30 - IO: LockFileAddtodatadirWrite

等待在向数据目录锁文件添加一行时写入数据。
PostgreSQL 等待事件档案
类别IO 事件LockFileAddtodatadirWrite 版本PG 17-18 证据4 个源码位置

官方描述译文

等待在向数据目录锁文件添加一行时写入数据。

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

历史名称：IO/LockFileAddToDataDirWrite (PG 13-16)

触发机制

WAIT_EVENT_LOCK_FILE_ADDTODATADIR_WRITE 位于 src/backend/utils/init/miscinit.c:1648，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:616。探针覆盖的操作是：等待在向数据目录锁文件添加一行时写入数据。PostgreSQL 在 LockFileAddtodatadirWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/LockFileAddtodatadirWrite 的会话 
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 = 'LockFileAddtodatadirWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LockFileAddtodatadirWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

31 - IO: LockFileCreateRead

等待在创建数据目录锁文件时读取数据。
PostgreSQL 等待事件档案
类别IO 事件LockFileCreateRead 版本PG 13-18 证据2 个源码位置

官方描述译文

等待在创建数据目录锁文件时读取数据。

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

触发机制

WAIT_EVENT_LOCK_FILE_CREATE_READ 位于 src/backend/utils/init/miscinit.c:1302，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:226。探针覆盖的操作是：等待在创建数据目录锁文件时读取数据。PostgreSQL 在 LockFileCreateRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/LockFileCreateRead 的会话 
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 = 'LockFileCreateRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LockFileCreateRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

32 - IO: LockFileCreateSync

等待创建数据目录锁文件时写入的数据到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件LockFileCreateSync 版本PG 13-18 证据2 个源码位置

官方描述译文

等待创建数据目录锁文件时写入的数据到达持久化存储。

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

触发机制

WAIT_EVENT_LOCK_FILE_CREATE_SYNC 位于 src/backend/utils/init/miscinit.c:1465，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:227。探针覆盖的操作是：等待创建数据目录锁文件时写入的数据到达持久化存储。PostgreSQL 在 LockFileCreateSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/LockFileCreateSync 的会话 
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 = 'LockFileCreateSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LockFileCreateSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

33 - IO: LockFileCreateWrite

等待在创建数据目录锁文件时写入数据。
PostgreSQL 等待事件档案
类别IO 事件LockFileCreateWrite 版本PG 13-18 证据2 个源码位置

官方描述译文

等待在创建数据目录锁文件时写入数据。

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

触发机制

WAIT_EVENT_LOCK_FILE_CREATE_WRITE 位于 src/backend/utils/init/miscinit.c:1450，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:228。探针覆盖的操作是：等待在创建数据目录锁文件时写入数据。PostgreSQL 在 LockFileCreateWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/LockFileCreateWrite 的会话 
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 = 'LockFileCreateWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LockFileCreateWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

34 - IO: LockFileRecheckdatadirRead

等待在重新检查数据目录锁文件时读取数据。
PostgreSQL 等待事件档案
类别IO 事件LockFileRecheckdatadirRead 版本PG 17-18 证据4 个源码位置

官方描述译文

等待在重新检查数据目录锁文件时读取数据。

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

历史名称：IO/LockFileReCheckDataDirRead (PG 13-16)

触发机制

WAIT_EVENT_LOCK_FILE_RECHECKDATADIR_READ 位于 src/backend/utils/init/miscinit.c:1728，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:628。探针覆盖的操作是：等待在重新检查数据目录锁文件时读取数据。PostgreSQL 在 LockFileRecheckdatadirRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/LockFileRecheckdatadirRead 的会话 
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 = 'LockFileRecheckdatadirRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LockFileRecheckdatadirRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

35 - IO: LogicalChangesRead

等待从逻辑变更文件中读取数据。
PostgreSQL 等待事件档案
类别IO 事件LogicalChangesRead 版本PG 14 证据1 个源码位置

官方描述译文

等待从逻辑变更文件中读取数据。

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

触发机制

目录中仍保留该身份，但源码审计确认在 14 已没有活动报告点。已知曾可触发范围：none。下方定义位置作为负面证据保留；当前精确版本不会从核心代码路径发出此事件。 证据：pgsql-hackers confirmation。

正常还是麻烦？

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

诊断 SQL

正在等待 IO/LogicalChangesRead 的会话 
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 = 'LogicalChangesRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LogicalChangesRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

36 - IO: LogicalChangesWrite

等待向逻辑变更文件写入数据。
PostgreSQL 等待事件档案
类别IO 事件LogicalChangesWrite 版本PG 14 证据1 个源码位置

官方描述译文

等待向逻辑变更文件写入数据。

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

触发机制

目录中仍保留该身份，但源码审计确认在 14 已没有活动报告点。已知曾可触发范围：none。下方定义位置作为负面证据保留；当前精确版本不会从核心代码路径发出此事件。 证据：pgsql-hackers confirmation。

正常还是麻烦？

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

诊断 SQL

正在等待 IO/LogicalChangesWrite 的会话 
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 = 'LogicalChangesWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LogicalChangesWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

37 - IO: LogicalRewriteCheckpointSync

等待检查点期间的逻辑重写映射到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件LogicalRewriteCheckpointSync 版本PG 13-18 证据2 个源码位置

官方描述译文

等待检查点期间的逻辑重写映射到达持久化存储。

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

触发机制

WAIT_EVENT_LOGICAL_REWRITE_CHECKPOINT_SYNC 位于 src/backend/access/heap/rewriteheap.c:1236，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:230。探针覆盖的操作是：等待检查点期间的逻辑重写映射到达持久化存储。PostgreSQL 在 LogicalRewriteCheckpointSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/LogicalRewriteCheckpointSync 的会话 
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 = 'LogicalRewriteCheckpointSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LogicalRewriteCheckpointSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

38 - IO: LogicalRewriteMappingSync

等待逻辑重写期间的映射数据到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件LogicalRewriteMappingSync 版本PG 13-18 证据2 个源码位置

官方描述译文

等待逻辑重写期间的映射数据到达持久化存储。

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

触发机制

WAIT_EVENT_LOGICAL_REWRITE_MAPPING_SYNC 位于 src/backend/access/heap/rewriteheap.c:1131，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:231。探针覆盖的操作是：等待逻辑重写期间的映射数据到达持久化存储。PostgreSQL 在 LogicalRewriteMappingSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/LogicalRewriteMappingSync 的会话 
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 = 'LogicalRewriteMappingSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LogicalRewriteMappingSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

39 - IO: LogicalRewriteMappingWrite

等待在逻辑重写期间写入映射数据。
PostgreSQL 等待事件档案
类别IO 事件LogicalRewriteMappingWrite 版本PG 13-18 证据2 个源码位置

官方描述译文

等待在逻辑重写期间写入映射数据。

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

触发机制

WAIT_EVENT_LOGICAL_REWRITE_MAPPING_WRITE 位于 src/backend/access/heap/rewriteheap.c:1114，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:232。探针覆盖的操作是：等待在逻辑重写期间写入映射数据。PostgreSQL 在 LogicalRewriteMappingWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/LogicalRewriteMappingWrite 的会话 
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 = 'LogicalRewriteMappingWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LogicalRewriteMappingWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

40 - IO: LogicalRewriteSync

等待逻辑重写映射到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件LogicalRewriteSync 版本PG 13-18 证据2 个源码位置

官方描述译文

等待逻辑重写映射到达持久化存储。

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

触发机制

WAIT_EVENT_LOGICAL_REWRITE_SYNC 位于 src/backend/access/heap/rewriteheap.c:922，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:233。探针覆盖的操作是：等待逻辑重写映射到达持久化存储。PostgreSQL 在 LogicalRewriteSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/LogicalRewriteSync 的会话 
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 = 'LogicalRewriteSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LogicalRewriteSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

41 - IO: LogicalRewriteTruncate

等待在逻辑重写期间截断映射数据。
PostgreSQL 等待事件档案
类别IO 事件LogicalRewriteTruncate 版本PG 13-18 证据2 个源码位置

官方描述译文

等待在逻辑重写期间截断映射数据。

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

触发机制

WAIT_EVENT_LOGICAL_REWRITE_TRUNCATE 位于 src/backend/access/heap/rewriteheap.c:1100，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:234。探针覆盖的操作是：等待在逻辑重写期间截断映射数据。PostgreSQL 在 LogicalRewriteTruncate 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/LogicalRewriteTruncate 的会话 
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 = 'LogicalRewriteTruncate'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LogicalRewriteTruncate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

42 - IO: LogicalRewriteWrite

等待写入逻辑重写映射。
PostgreSQL 等待事件档案
类别IO 事件LogicalRewriteWrite 版本PG 13-18 证据2 个源码位置

官方描述译文

等待写入逻辑重写映射。

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

触发机制

WAIT_EVENT_LOGICAL_REWRITE_WRITE 位于 src/backend/access/heap/rewriteheap.c:881，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:235。探针覆盖的操作是：等待写入逻辑重写映射。PostgreSQL 在 LogicalRewriteWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/LogicalRewriteWrite 的会话 
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 = 'LogicalRewriteWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LogicalRewriteWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

43 - IO: LogicalSubxactRead

等待从逻辑子事务文件中读取数据。
PostgreSQL 等待事件档案
类别IO 事件LogicalSubxactRead 版本PG 14 证据1 个源码位置

官方描述译文

等待从逻辑子事务文件中读取数据。

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

触发机制

目录中仍保留该身份，但源码审计确认在 14 已没有活动报告点。已知曾可触发范围：none。下方定义位置作为负面证据保留；当前精确版本不会从核心代码路径发出此事件。 证据：pgsql-hackers confirmation。

正常还是麻烦？

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

诊断 SQL

正在等待 IO/LogicalSubxactRead 的会话 
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 = 'LogicalSubxactRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LogicalSubxactRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

44 - IO: LogicalSubxactWrite

等待向逻辑子事务文件写入数据。
PostgreSQL 等待事件档案
类别IO 事件LogicalSubxactWrite 版本PG 14 证据1 个源码位置

官方描述译文

等待向逻辑子事务文件写入数据。

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

触发机制

目录中仍保留该身份，但源码审计确认在 14 已没有活动报告点。已知曾可触发范围：none。下方定义位置作为负面证据保留；当前精确版本不会从核心代码路径发出此事件。 证据：pgsql-hackers confirmation。

正常还是麻烦？

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

诊断 SQL

正在等待 IO/LogicalSubxactWrite 的会话 
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 = 'LogicalSubxactWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'LogicalSubxactWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

45 - IO: RelationMapRead

等待读取 relation map 文件。
PostgreSQL 等待事件档案
类别IO 事件RelationMapRead 版本PG 13-18 证据2 个源码位置

官方描述译文

等待读取 relation map 文件。

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

触发机制

WAIT_EVENT_RELATION_MAP_READ 位于 src/backend/utils/cache/relmapper.c:822，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:236。探针覆盖的操作是：等待读取 relation map 文件。PostgreSQL 在 RelationMapRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/RelationMapRead 的会话 
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 = 'RelationMapRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'RelationMapRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

46 - IO: RelationMapReplace

等待以持久化方式替换 relation map 文件。
PostgreSQL 等待事件档案
类别IO 事件RelationMapReplace 版本PG 16-18 证据2 个源码位置

官方描述译文

等待以持久化方式替换 relation map 文件。

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

触发机制

WAIT_EVENT_RELATION_MAP_REPLACE 位于 src/backend/utils/cache/relmapper.c:988，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:237。探针覆盖的操作是：等待以持久化方式替换 relation map 文件。PostgreSQL 在 RelationMapReplace 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/RelationMapReplace 的会话 
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 = 'RelationMapReplace'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'RelationMapReplace'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

47 - IO: RelationMapSync

等待 relation map 文件到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件RelationMapSync 版本PG 13-15 证据2 个源码位置

官方描述译文

等待 relation map 文件到达持久化存储。

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

触发机制

WAIT_EVENT_RELATION_MAP_SYNC 位于 src/backend/utils/cache/relmapper.c:957，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:637。探针覆盖的操作是：等待 relation map 文件到达持久化存储。PostgreSQL 在 RelationMapSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/RelationMapSync 的会话 
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 = 'RelationMapSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'RelationMapSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

48 - IO: RelationMapWrite

等待向 relation map 文件写入数据。
PostgreSQL 等待事件档案
类别IO 事件RelationMapWrite 版本PG 13-18 证据2 个源码位置

官方描述译文

等待向 relation map 文件写入数据。

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

触发机制

WAIT_EVENT_RELATION_MAP_WRITE 位于 src/backend/utils/cache/relmapper.c:939，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:238。探针覆盖的操作是：等待向 relation map 文件写入数据。PostgreSQL 在 RelationMapWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/RelationMapWrite 的会话 
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 = 'RelationMapWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'RelationMapWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

49 - IO: ReorderBufferRead

等待在 reorder buffer 管理期间读取数据。
PostgreSQL 等待事件档案
类别IO 事件ReorderBufferRead 版本PG 13-18 证据2 个源码位置

官方描述译文

等待在 reorder buffer 管理期间读取数据。

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

触发机制

WAIT_EVENT_REORDER_BUFFER_READ 位于 src/backend/replication/logical/reorderbuffer.c:4609，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:239。探针覆盖的操作是：等待在 reorder buffer 管理期间读取数据。PostgreSQL 在 ReorderBufferRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/ReorderBufferRead 的会话 
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 = 'ReorderBufferRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'ReorderBufferRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

50 - IO: ReorderBufferWrite

等待在 reorder buffer 管理期间写入数据。
PostgreSQL 等待事件档案
类别IO 事件ReorderBufferWrite 版本PG 13-18 证据2 个源码位置

官方描述译文

等待在 reorder buffer 管理期间写入数据。

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

触发机制

WAIT_EVENT_REORDER_BUFFER_WRITE 位于 src/backend/replication/logical/reorderbuffer.c:4265，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:240。探针覆盖的操作是：等待在 reorder buffer 管理期间写入数据。PostgreSQL 在 ReorderBufferWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/ReorderBufferWrite 的会话 
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 = 'ReorderBufferWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'ReorderBufferWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

51 - IO: ReorderLogicalMappingRead

等待在 reorder buffer 管理期间读取逻辑映射。
PostgreSQL 等待事件档案
类别IO 事件ReorderLogicalMappingRead 版本PG 13-18 证据2 个源码位置

官方描述译文

等待在 reorder buffer 管理期间读取逻辑映射。

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

触发机制

WAIT_EVENT_REORDER_LOGICAL_MAPPING_READ 位于 src/backend/replication/logical/reorderbuffer.c:5383，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:241。探针覆盖的操作是：等待在 reorder buffer 管理期间读取逻辑映射。PostgreSQL 在 ReorderLogicalMappingRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/ReorderLogicalMappingRead 的会话 
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 = 'ReorderLogicalMappingRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'ReorderLogicalMappingRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

52 - IO: ReplicationSlotRead

等待从复制槽控制文件中读取数据。
PostgreSQL 等待事件档案
类别IO 事件ReplicationSlotRead 版本PG 13-18 证据2 个源码位置

官方描述译文

等待从复制槽控制文件中读取数据。

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

触发机制

WAIT_EVENT_REPLICATION_SLOT_READ 位于 src/backend/replication/slot.c:2540，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:242。探针覆盖的操作是：等待从复制槽控制文件中读取数据。PostgreSQL 在 ReplicationSlotRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/ReplicationSlotRead 的会话 
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 = 'ReplicationSlotRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'ReplicationSlotRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

53 - IO: ReplicationSlotRestoreSync

等待在将复制槽恢复到内存的过程中，使其控制文件到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件ReplicationSlotRestoreSync 版本PG 13-18 证据2 个源码位置

官方描述译文

等待在将复制槽恢复到内存的过程中，使其控制文件到达持久化存储。

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

触发机制

WAIT_EVENT_REPLICATION_SLOT_RESTORE_SYNC 位于 src/backend/replication/slot.c:2526，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:243。探针覆盖的操作是：等待在将复制槽恢复到内存的过程中，使其控制文件到达持久化存储。PostgreSQL 在 ReplicationSlotRestoreSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/ReplicationSlotRestoreSync 的会话 
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 = 'ReplicationSlotRestoreSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'ReplicationSlotRestoreSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

54 - IO: ReplicationSlotSync

等待复制槽控制文件到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件ReplicationSlotSync 版本PG 13-18 证据2 个源码位置

官方描述译文

等待复制槽控制文件到达持久化存储。

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

触发机制

WAIT_EVENT_REPLICATION_SLOT_SYNC 位于 src/backend/replication/slot.c:2405，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:244。探针覆盖的操作是：等待复制槽控制文件到达持久化存储。PostgreSQL 在 ReplicationSlotSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/ReplicationSlotSync 的会话 
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 = 'ReplicationSlotSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'ReplicationSlotSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

55 - IO: ReplicationSlotWrite

等待向复制槽控制文件写入数据。
PostgreSQL 等待事件档案
类别IO 事件ReplicationSlotWrite 版本PG 13-18 证据2 个源码位置

官方描述译文

等待向复制槽控制文件写入数据。

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

触发机制

WAIT_EVENT_REPLICATION_SLOT_WRITE 位于 src/backend/replication/slot.c:2384，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:245。探针覆盖的操作是：等待向复制槽控制文件写入数据。PostgreSQL 在 ReplicationSlotWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/ReplicationSlotWrite 的会话 
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 = 'ReplicationSlotWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'ReplicationSlotWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

56 - IO: SlruFlushSync

等待检查点或数据库关闭期间的 SLRU 数据到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件SlruFlushSync 版本PG 17-18 证据4 个源码位置

官方描述译文

等待检查点或数据库关闭期间的 SLRU 数据到达持久化存储。

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

历史名称：IO/SLRUFlushSync (PG 13-16)

触发机制

WAIT_EVENT_SLRU_FLUSH_SYNC 位于 src/backend/access/transam/slru.c:1606，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:679。探针覆盖的操作是：等待检查点或数据库关闭期间的 SLRU 数据到达持久化存储。PostgreSQL 在 SlruFlushSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/SlruFlushSync 的会话 
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 = 'SlruFlushSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'SlruFlushSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

57 - IO: SlruRead

等待读取 SLRU 页面。
PostgreSQL 等待事件档案
类别IO 事件SlruRead 版本PG 17-18 证据4 个源码位置

官方描述译文

等待读取 SLRU 页面。

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

历史名称：IO/SLRURead (PG 13-16)

触发机制

WAIT_EVENT_SLRU_READ 位于 src/backend/access/transam/slru.c:721，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:682。探针覆盖的操作是：等待读取 SLRU 页面。PostgreSQL 在 SlruRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/SlruRead 的会话 
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 = 'SlruRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'SlruRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

58 - IO: SlruSync

等待页面写入后的 SLRU 数据到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件SlruSync 版本PG 17-18 证据4 个源码位置

官方描述译文

等待页面写入后的 SLRU 数据到达持久化存储。

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

历史名称：IO/SLRUSync (PG 13-16)

触发机制

WAIT_EVENT_SLRU_SYNC 位于 src/backend/access/transam/slru.c:900，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:685。探针覆盖的操作是：等待页面写入后的 SLRU 数据到达持久化存储。PostgreSQL 在 SlruSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/SlruSync 的会话 
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 = 'SlruSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'SlruSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

59 - IO: SlruWrite

等待写入 SLRU 页面。
PostgreSQL 等待事件档案
类别IO 事件SlruWrite 版本PG 17-18 证据4 个源码位置

官方描述译文

等待写入 SLRU 页面。

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

历史名称：IO/SLRUWrite (PG 13-16)

触发机制

WAIT_EVENT_SLRU_WRITE 位于 src/backend/access/transam/slru.c:876，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:688。探针覆盖的操作是：等待写入 SLRU 页面。PostgreSQL 在 SlruWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/SlruWrite 的会话 
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 = 'SlruWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'SlruWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

60 - IO: SnapbuildRead

等待读取序列化的历史系统目录 snapshot。
PostgreSQL 等待事件档案
类别IO 事件SnapbuildRead 版本PG 13-18 证据2 个源码位置

官方描述译文

等待读取序列化的历史系统目录 snapshot。

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

触发机制

WAIT_EVENT_SNAPBUILD_READ 位于 src/backend/replication/logical/snapbuild.c:1937，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:250。探针覆盖的操作是：等待读取序列化的历史系统目录 snapshot。PostgreSQL 在 SnapbuildRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/SnapbuildRead 的会话 
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 = 'SnapbuildRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'SnapbuildRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

61 - IO: SnapbuildSync

等待序列化的历史系统目录 snapshot 到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件SnapbuildSync 版本PG 13-18 证据2 个源码位置

官方描述译文

等待序列化的历史系统目录 snapshot 到达持久化存储。

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

触发机制

WAIT_EVENT_SNAPBUILD_SYNC 位于 src/backend/replication/logical/snapbuild.c:1680，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:251。探针覆盖的操作是：等待序列化的历史系统目录 snapshot 到达持久化存储。PostgreSQL 在 SnapbuildSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/SnapbuildSync 的会话 
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 = 'SnapbuildSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'SnapbuildSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

62 - IO: SnapbuildWrite

等待写入序列化的历史系统目录 snapshot。
PostgreSQL 等待事件档案
类别IO 事件SnapbuildWrite 版本PG 13-18 证据2 个源码位置

官方描述译文

等待写入序列化的历史系统目录 snapshot。

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

触发机制

WAIT_EVENT_SNAPBUILD_WRITE 位于 src/backend/replication/logical/snapbuild.c:1654，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:252。探针覆盖的操作是：等待写入序列化的历史系统目录 snapshot。PostgreSQL 在 SnapbuildWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/SnapbuildWrite 的会话 
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 = 'SnapbuildWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'SnapbuildWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

63 - IO: TimelineHistoryFileSync

等待通过流复制接收的时间线历史文件到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件TimelineHistoryFileSync 版本PG 13-18 证据2 个源码位置

官方描述译文

等待通过流复制接收的时间线历史文件到达持久化存储。

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

触发机制

WAIT_EVENT_TIMELINE_HISTORY_FILE_SYNC 位于 src/backend/access/transam/timeline.c:502，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:253。探针覆盖的操作是：等待通过流复制接收的时间线历史文件到达持久化存储。PostgreSQL 在 TimelineHistoryFileSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/TimelineHistoryFileSync 的会话 
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 = 'TimelineHistoryFileSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'TimelineHistoryFileSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

64 - IO: TimelineHistoryFileWrite

等待写入通过流复制接收的时间线历史文件。
PostgreSQL 等待事件档案
类别IO 事件TimelineHistoryFileWrite 版本PG 13-18 证据2 个源码位置

官方描述译文

等待写入通过流复制接收的时间线历史文件。

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

触发机制

WAIT_EVENT_TIMELINE_HISTORY_FILE_WRITE 位于 src/backend/access/transam/timeline.c:484，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:254。探针覆盖的操作是：等待写入通过流复制接收的时间线历史文件。PostgreSQL 在 TimelineHistoryFileWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/TimelineHistoryFileWrite 的会话 
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 = 'TimelineHistoryFileWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'TimelineHistoryFileWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

65 - IO: TimelineHistoryRead

等待读取时间线历史文件。
PostgreSQL 等待事件档案
类别IO 事件TimelineHistoryRead 版本PG 13-18 证据2 个源码位置

官方描述译文

等待读取时间线历史文件。

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

触发机制

WAIT_EVENT_TIMELINE_HISTORY_READ 位于 src/backend/access/transam/timeline.c:135，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:255。探针覆盖的操作是：等待读取时间线历史文件。PostgreSQL 在 TimelineHistoryRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/TimelineHistoryRead 的会话 
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 = 'TimelineHistoryRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'TimelineHistoryRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

66 - IO: TimelineHistorySync

等待新建的时间线历史文件到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件TimelineHistorySync 版本PG 13-18 证据2 个源码位置

官方描述译文

等待新建的时间线历史文件到达持久化存储。

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

触发机制

WAIT_EVENT_TIMELINE_HISTORY_SYNC 位于 src/backend/access/transam/timeline.c:428，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:256。探针覆盖的操作是：等待新建的时间线历史文件到达持久化存储。PostgreSQL 在 TimelineHistorySync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/TimelineHistorySync 的会话 
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 = 'TimelineHistorySync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'TimelineHistorySync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

67 - IO: TimelineHistoryWrite

等待写入新建的时间线历史文件。
PostgreSQL 等待事件档案
类别IO 事件TimelineHistoryWrite 版本PG 13-18 证据2 个源码位置

官方描述译文

等待写入新建的时间线历史文件。

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

触发机制

WAIT_EVENT_TIMELINE_HISTORY_WRITE 位于 src/backend/access/transam/timeline.c:366，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:257。探针覆盖的操作是：等待写入新建的时间线历史文件。PostgreSQL 在 TimelineHistoryWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/TimelineHistoryWrite 的会话 
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 = 'TimelineHistoryWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'TimelineHistoryWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

68 - IO: TwophaseFileRead

等待读取两阶段状态文件。
PostgreSQL 等待事件档案
类别IO 事件TwophaseFileRead 版本PG 13-18 证据2 个源码位置

官方描述译文

等待读取两阶段状态文件。

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

触发机制

WAIT_EVENT_TWOPHASE_FILE_READ 位于 src/backend/access/transam/twophase.c:1347，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:258。探针覆盖的操作是：等待读取两阶段状态文件。PostgreSQL 在 TwophaseFileRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/TwophaseFileRead 的会话 
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 = 'TwophaseFileRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'TwophaseFileRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

69 - IO: TwophaseFileSync

等待两阶段状态文件到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件TwophaseFileSync 版本PG 13-18 证据2 个源码位置

官方描述译文

等待两阶段状态文件到达持久化存储。

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

触发机制

WAIT_EVENT_TWOPHASE_FILE_SYNC 位于 src/backend/access/transam/twophase.c:1774，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:259。探针覆盖的操作是：等待两阶段状态文件到达持久化存储。PostgreSQL 在 TwophaseFileSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/TwophaseFileSync 的会话 
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 = 'TwophaseFileSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'TwophaseFileSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

70 - IO: TwophaseFileWrite

等待写入两阶段状态文件。
PostgreSQL 等待事件档案
类别IO 事件TwophaseFileWrite 版本PG 13-18 证据2 个源码位置

官方描述译文

等待写入两阶段状态文件。

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

触发机制

WAIT_EVENT_TWOPHASE_FILE_WRITE 位于 src/backend/access/transam/twophase.c:1749，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:260。探针覆盖的操作是：等待写入两阶段状态文件。PostgreSQL 在 TwophaseFileWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/TwophaseFileWrite 的会话 
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 = 'TwophaseFileWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'TwophaseFileWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

71 - IO: VersionFileSync

等待创建数据库时的版本文件到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件VersionFileSync 版本PG 15-18 证据2 个源码位置

官方描述译文

等待创建数据库时的版本文件到达持久化存储。

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

触发机制

WAIT_EVENT_VERSION_FILE_SYNC 位于 src/backend/commands/dbcommands.c:511，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:261。探针覆盖的操作是：等待创建数据库时的版本文件到达持久化存储。PostgreSQL 在 VersionFileSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/VersionFileSync 的会话 
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 = 'VersionFileSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'VersionFileSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

72 - IO: VersionFileWrite

等待在创建数据库时写入版本文件。
PostgreSQL 等待事件档案
类别IO 事件VersionFileWrite 版本PG 15-18 证据2 个源码位置

官方描述译文

等待在创建数据库时写入版本文件。

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

触发机制

WAIT_EVENT_VERSION_FILE_WRITE 位于 src/backend/commands/dbcommands.c:498，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:262。探针覆盖的操作是：等待在创建数据库时写入版本文件。PostgreSQL 在 VersionFileWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/VersionFileWrite 的会话 
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 = 'VersionFileWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'VersionFileWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

73 - IO: WalBootstrapSync

等待引导初始化期间的 WAL 到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件WalBootstrapSync 版本PG 17-18 证据4 个源码位置

官方描述译文

等待引导初始化期间的 WAL 到达持久化存储。

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

历史名称：IO/WALBootstrapSync (PG 13-16)

触发机制

WAIT_EVENT_WAL_BOOTSTRAP_SYNC 位于 src/backend/access/transam/xlog.c:4776，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:733。探针覆盖的操作是：等待引导初始化期间的 WAL 到达持久化存储。PostgreSQL 在 WalBootstrapSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/WalBootstrapSync 的会话 
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 = 'WalBootstrapSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'WalBootstrapSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

74 - IO: WalBootstrapWrite

等待在引导初始化期间写入 WAL 页面。
PostgreSQL 等待事件档案
类别IO 事件WalBootstrapWrite 版本PG 17-18 证据4 个源码位置

官方描述译文

等待在引导初始化期间写入 WAL 页面。

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

历史名称：IO/WALBootstrapWrite (PG 13-16)

触发机制

WAIT_EVENT_WAL_BOOTSTRAP_WRITE 位于 src/backend/access/transam/xlog.c:4764，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:736。探针覆盖的操作是：等待在引导初始化期间写入 WAL 页面。PostgreSQL 在 WalBootstrapWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/WalBootstrapWrite 的会话 
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 = 'WalBootstrapWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'WalBootstrapWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

75 - IO: WalCopyRead

等待通过复制现有 WAL segment 创建新 WAL segment 时读取数据。
PostgreSQL 等待事件档案
类别IO 事件WalCopyRead 版本PG 17-18 证据4 个源码位置

官方描述译文

等待通过复制现有 WAL segment 创建新 WAL segment 时读取数据。

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

历史名称：IO/WALCopyRead (PG 13-16)

触发机制

WAIT_EVENT_WAL_COPY_READ 位于 src/backend/access/transam/xlog.c:3190，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:739。探针覆盖的操作是：等待通过复制现有 WAL segment 创建新 WAL segment 时读取数据。PostgreSQL 在 WalCopyRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/WalCopyRead 的会话 
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 = 'WalCopyRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'WalCopyRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

76 - IO: WalCopySync

等待通过复制现有 WAL segment 创建的新 WAL segment 到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件WalCopySync 版本PG 17-18 证据4 个源码位置

官方描述译文

等待通过复制现有 WAL segment 创建的新 WAL segment 到达持久化存储。

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

历史名称：IO/WALCopySync (PG 13-16)

触发机制

WAIT_EVENT_WAL_COPY_SYNC 位于 src/backend/access/transam/xlog.c:3227，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:742。探针覆盖的操作是：等待通过复制现有 WAL segment 创建的新 WAL segment 到达持久化存储。PostgreSQL 在 WalCopySync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/WalCopySync 的会话 
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 = 'WalCopySync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'WalCopySync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

77 - IO: WalCopyWrite

等待通过复制现有 WAL segment 创建新 WAL segment 时写入数据。
PostgreSQL 等待事件档案
类别IO 事件WalCopyWrite 版本PG 17-18 证据4 个源码位置

官方描述译文

等待通过复制现有 WAL segment 创建新 WAL segment 时写入数据。

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

历史名称：IO/WALCopyWrite (PG 13-16)

触发机制

WAIT_EVENT_WAL_COPY_WRITE 位于 src/backend/access/transam/xlog.c:3208，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:745。探针覆盖的操作是：等待通过复制现有 WAL segment 创建新 WAL segment 时写入数据。PostgreSQL 在 WalCopyWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/WalCopyWrite 的会话 
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 = 'WalCopyWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'WalCopyWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

78 - IO: WalInitSync

等待新初始化的 WAL 文件到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件WalInitSync 版本PG 17-18 证据4 个源码位置

官方描述译文

等待新初始化的 WAL 文件到达持久化存储。

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

历史名称：IO/WALInitSync (PG 13-16)

触发机制

WAIT_EVENT_WAL_INIT_SYNC 位于 src/backend/access/transam/xlog.c:3028，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:748。探针覆盖的操作是：等待新初始化的 WAL 文件到达持久化存储。PostgreSQL 在 WalInitSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/WalInitSync 的会话 
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 = 'WalInitSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'WalInitSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

79 - IO: WalInitWrite

等待在初始化新 WAL 文件时写入数据。
PostgreSQL 等待事件档案
类别IO 事件WalInitWrite 版本PG 17-18 证据4 个源码位置

官方描述译文

等待在初始化新 WAL 文件时写入数据。

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

历史名称：IO/WALInitWrite (PG 13-16)

触发机制

WAIT_EVENT_WAL_INIT_WRITE 位于 src/backend/access/transam/xlog.c:2977，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:751。探针覆盖的操作是：等待在初始化新 WAL 文件时写入数据。PostgreSQL 在 WalInitWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/WalInitWrite 的会话 
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 = 'WalInitWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'WalInitWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

80 - IO: WalRead

等待从 WAL 文件中读取数据。
PostgreSQL 等待事件档案
类别IO 事件WalRead 版本PG 17-18 证据4 个源码位置

官方描述译文

等待从 WAL 文件中读取数据。

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

历史名称：IO/WALRead (PG 13-16)

触发机制

WAIT_EVENT_WAL_READ 位于 src/backend/access/transam/xlogreader.c:1570，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:754。探针覆盖的操作是：等待从 WAL 文件中读取数据。PostgreSQL 在 WalRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/WalRead 的会话 
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 = 'WalRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'WalRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

81 - IO: WalSummaryRead

等待从 WAL summary 文件中读取数据。
PostgreSQL 等待事件档案
类别IO 事件WalSummaryRead 版本PG 17-18 证据2 个源码位置

官方描述译文

等待从 WAL summary 文件中读取数据。

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

触发机制

WAIT_EVENT_WAL_SUMMARY_READ 位于 src/backend/backup/walsummary.c:279，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:272。探针覆盖的操作是：等待从 WAL summary 文件中读取数据。PostgreSQL 在 WalSummaryRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/WalSummaryRead 的会话 
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 = 'WalSummaryRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'WalSummaryRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

82 - IO: WalSummaryWrite

等待向 WAL summary 文件写入数据。
PostgreSQL 等待事件档案
类别IO 事件WalSummaryWrite 版本PG 17-18 证据2 个源码位置

官方描述译文

等待向 WAL summary 文件写入数据。

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

触发机制

WAIT_EVENT_WAL_SUMMARY_WRITE 位于 src/backend/backup/walsummary.c:300，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:273。探针覆盖的操作是：等待向 WAL summary 文件写入数据。PostgreSQL 在 WalSummaryWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/WalSummaryWrite 的会话 
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 = 'WalSummaryWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'WalSummaryWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

83 - IO: WalSync

等待 WAL 文件到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件WalSync 版本PG 17-18 证据4 个源码位置

官方描述译文

等待 WAL 文件到达持久化存储。

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

历史名称：IO/WALSync (PG 13-16)

触发机制

WAIT_EVENT_WAL_SYNC 位于 src/backend/access/transam/xlog.c:8303，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:757。探针覆盖的操作是：等待 WAL 文件到达持久化存储。PostgreSQL 在 WalSync 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/WalSync 的会话 
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 = 'WalSync'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'WalSync'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

84 - IO: WalSyncMethodAssign

等待分配新的 WAL 同步方法时写入的数据到达持久化存储。
PostgreSQL 等待事件档案
类别IO 事件WalSyncMethodAssign 版本PG 17-18 证据4 个源码位置

官方描述译文

等待分配新的 WAL 同步方法时写入的数据到达持久化存储。

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

历史名称：IO/WALSyncMethodAssign (PG 13-16)

触发机制

WAIT_EVENT_WAL_SYNC_METHOD_ASSIGN 位于 src/backend/access/transam/xlog.c:8251，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:760。探针覆盖的操作是：等待分配新的 WAL 同步方法时写入的数据到达持久化存储。PostgreSQL 在 WalSyncMethodAssign 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/WalSyncMethodAssign 的会话 
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 = 'WalSyncMethodAssign'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'WalSyncMethodAssign'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

85 - IO: WalWrite

等待向 WAL 文件写入数据。
PostgreSQL 等待事件档案
类别IO 事件WalWrite 版本PG 17-18 证据4 个源码位置

官方描述译文

等待向 WAL 文件写入数据。

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

历史名称：IO/WALWrite (PG 13-16)

触发机制

WAIT_EVENT_WAL_WRITE 位于 src/backend/access/transam/xlog.c:2200，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:763。探针覆盖的操作是：等待向 WAL 文件写入数据。PostgreSQL 在 WalWrite 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/WalWrite 的会话 
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 = 'WalWrite'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'WalWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号

86 - IO: WalsenderTimelineHistoryRead

等待在 WAL sender 执行 timeline 命令期间从时间线历史文件中读取数据。
PostgreSQL 等待事件档案
类别IO 事件WalsenderTimelineHistoryRead 版本PG 17-18 证据4 个源码位置

官方描述译文

等待在 WAL sender 执行 timeline 命令期间从时间线历史文件中读取数据。

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

历史名称：IO/WALSenderTimelineHistoryRead (PG 13-16)

触发机制

WAIT_EVENT_WALSENDER_TIMELINE_HISTORY_READ 位于 src/backend/replication/walsender.c:654，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:730。探针覆盖的操作是：等待在 WAL sender 执行 timeline 命令期间从时间线历史文件中读取数据。PostgreSQL 在 WalsenderTimelineHistoryRead 所表示的文件或异步 I/O 操作周围报告此事件；内核、存储栈或 I/O worker 完成该步骤后，后端继续执行。

正常还是麻烦？

  • 正常: 当负载本来就应以当前速率执行对应的读取、写入、同步、分配或完成操作时，这项等待正常。
  • 需要调查: 若它持续存在并伴随前台延迟、大量并发等待者、存储长尾延迟、限速或错误，应当调查。

诊断 SQL

正在等待 IO/WalsenderTimelineHistoryRead 的会话 
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 = 'WalsenderTimelineHistoryRead'
ORDER BY query_age DESC NULLS LAST;
当前 IO 等待分布 
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 = 'WalsenderTimelineHistoryRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 确认当前负载阶段本来就应访问这类文件。
  2. 在可用版本上关联 pg_stat_io 与具体设备延迟。
  3. 先修复访问路径、突发形状或受影响存储层，再调整无关的内存参数。

源码证据

关联控制项与信号