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

Timeout 等待

有意休眠、重试间隔、节流与限速延迟。

1: Timeout: BaseBackupThrottle
2: Timeout: CheckpointWriteDelay
3: Timeout: PgSleep
4: Timeout: RecoveryApplyDelay
5: Timeout: RecoveryRetrieveRetryInterval
6: Timeout: RegisterSyncRequest
7: Timeout: SpinDelay
8: Timeout: VacuumDelay
9: Timeout: VacuumTruncate
10: Timeout: WalSummarizerError

Timeout 通常表示 PostgreSQL 有意延迟工作，直到计时器到期。关键问题不是“内核为什么慢”，而是“哪条策略或安全机制插入了这段延迟”。

找到策略责任方

Vacuum 成本延迟、恢复延迟、备份节流、检查点摊平、重试间隔与 pg_sleep() 都是设计好的等待。当策略不再匹配服务目标，或另一瓶颈让延迟过度重复时，它们才成为问题。

正常： 配置策略正在生效，而且有效工作按预期速率推进。
关注： 前台延迟包含有意休眠，或维护任务大量时间都在节流而逐渐落后。
紧急： 恢复/备份/检查点错过时限、spin delay 持续，或运维人员并未打算启用这条策略。

值得先认出的事件

事件	策略
VacuumDelay	基于成本的 vacuum 节流
CheckpointWriteDelay	把检查点写入摊平到整个间隔
RecoveryApplyDelay	有意延迟备库回放
RecoveryRetrieveRetryInterval	对不可用 WAL 源进行重试
BaseBackupThrottle	备份传输限速
PgSleep	SQL 或内部 sleep 函数
SpinDelay	获取竞争 spinlock 时退避

常见误读

Timeout 不表示 statement timeout 或 lock timeout 已经触发；它表示进程此刻在计时器上休眠。
减少 vacuum delay 能恢复维护吞吐，但也可能增加 I/O 与 CPU 压力。
RecoveryApplyDelay 可能是有意的灾备策略。
持续的 SpinDelay 应当升级处理：spinlock 正常只会被持有极短时间。

1 - Timeout: BaseBackupThrottle

基础备份期间，因限速而等待。

PostgreSQL 等待事件档案

类别Timeout 事件BaseBackupThrottle 版本PG 13-18 证据2 个源码位置

官方描述译文

基础备份期间，因限速而等待。

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

触发机制

WAIT_EVENT_BASE_BACKUP_THROTTLE 位于 src/backend/backup/basebackup_throttle.c:178，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:175。探针覆盖的操作是：基础备份期间，因限速而等待。BaseBackupThrottle 路径有意等待计时器、重试间隔、节流或安全退避；latch 超时后才重新评估工作。

正常还是麻烦？

正常: 当配置策略是有意的，而且有效工作按预期速率推进时，这项等待正常。
需要调查: 策略导致维护、恢复、备份或延迟目标无法达成，或者 spin delay 持续时，应当调查。

诊断 SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
  AND wait_event = 'BaseBackupThrottle'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'BaseBackupThrottle'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

确认拥有该计时器的 GUC 或函数。
比较有效工作量与延迟时间。
先检查它原本要控制的 CPU、I/O 与持久性压力，再调整策略。

源码证据

PostgreSQL 18.6 · src/backend/backup/basebackup_throttle.c:178 — WAIT_EVENT_BASE_BACKUP_THROTTLE
PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:175 — BASE_BACKUP_THROTTLE

GUC: 无直接关联项。
指标: [metric:waiting_sessions] · [metric:wait_event_share]

2 - Timeout: CheckpointWriteDelay

执行检查点时，在两次写入之间等待。

PostgreSQL 等待事件档案

类别Timeout 事件CheckpointWriteDelay 版本PG 14-18 证据2 个源码位置

官方描述译文

执行检查点时，在两次写入之间等待。

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

触发机制

WAIT_EVENT_CHECKPOINT_WRITE_DELAY 位于 src/backend/postmaster/checkpointer.c:814，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:176。探针覆盖的操作是：执行检查点时，在两次写入之间等待。CheckpointWriteDelay 路径有意等待计时器、重试间隔、节流或安全退避；latch 超时后才重新评估工作。

正常还是麻烦？

正常: 当配置策略是有意的，而且有效工作按预期速率推进时，这项等待正常。
需要调查: 策略导致维护、恢复、备份或延迟目标无法达成，或者 spin delay 持续时，应当调查。

诊断 SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
  AND wait_event = 'CheckpointWriteDelay'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'CheckpointWriteDelay'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

确认拥有该计时器的 GUC 或函数。
比较有效工作量与延迟时间。
先检查它原本要控制的 CPU、I/O 与持久性压力，再调整策略。

源码证据

PostgreSQL 18.6 · src/backend/postmaster/checkpointer.c:814 — WAIT_EVENT_CHECKPOINT_WRITE_DELAY
PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:176 — CHECKPOINT_WRITE_DELAY

GUC: [guc:checkpoint_timeout] · [guc:max_wal_size]
指标: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:checkpoint_time]

3 - Timeout: PgSleep

因调用 pg_sleep 或同类函数而等待。

PostgreSQL 等待事件档案

类别Timeout 事件PgSleep 版本PG 13-18 证据2 个源码位置

官方描述译文

因调用 pg_sleep 或同类函数而等待。

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

触发机制

WAIT_EVENT_PG_SLEEP 位于 src/backend/utils/adt/misc.c:409，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:177。探针覆盖的操作是：因调用 pg_sleep 或同类函数而等待。PgSleep 路径有意等待计时器、重试间隔、节流或安全退避；latch 超时后才重新评估工作。

正常还是麻烦？

正常: 当配置策略是有意的，而且有效工作按预期速率推进时，这项等待正常。
需要调查: 策略导致维护、恢复、备份或延迟目标无法达成，或者 spin delay 持续时，应当调查。

诊断 SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
  AND wait_event = 'PgSleep'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'PgSleep'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

确认拥有该计时器的 GUC 或函数。
比较有效工作量与延迟时间。
先检查它原本要控制的 CPU、I/O 与持久性压力，再调整策略。

源码证据

PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:177 — PG_SLEEP
PostgreSQL 18.6 · src/backend/utils/adt/misc.c:409 — WAIT_EVENT_PG_SLEEP

GUC: 无直接关联项。
指标: [metric:waiting_sessions] · [metric:wait_event_share]

4 - Timeout: RecoveryApplyDelay

恢复期间，因延迟设置而等待应用 WAL。

PostgreSQL 等待事件档案

类别Timeout 事件RecoveryApplyDelay 版本PG 13-18 证据2 个源码位置

官方描述译文

恢复期间，因延迟设置而等待应用 WAL。

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

触发机制

WAIT_EVENT_RECOVERY_APPLY_DELAY 位于 src/backend/access/transam/xlogrecovery.c:3092，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:178。探针覆盖的操作是：恢复期间，因延迟设置而等待应用 WAL。RecoveryApplyDelay 路径有意等待计时器、重试间隔、节流或安全退避；latch 超时后才重新评估工作。

正常还是麻烦？

正常: 当配置策略是有意的，而且有效工作按预期速率推进时，这项等待正常。
需要调查: 策略导致维护、恢复、备份或延迟目标无法达成，或者 spin delay 持续时，应当调查。

诊断 SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
  AND wait_event = 'RecoveryApplyDelay'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'RecoveryApplyDelay'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

确认拥有该计时器的 GUC 或函数。
比较有效工作量与延迟时间。
先检查它原本要控制的 CPU、I/O 与持久性压力，再调整策略。

源码证据

PostgreSQL 18.6 · src/backend/access/transam/xlogrecovery.c:3092 — WAIT_EVENT_RECOVERY_APPLY_DELAY
PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:178 — RECOVERY_APPLY_DELAY

GUC: 无直接关联项。
指标: [metric:waiting_sessions] · [metric:wait_event_share]

5 - Timeout: RecoveryRetrieveRetryInterval

恢复期间，当所有来源（pg_wal、归档或流式传输）均无 WAL 数据可用时等待。

PostgreSQL 等待事件档案

类别Timeout 事件RecoveryRetrieveRetryInterval 版本PG 13-18 证据2 个源码位置

官方描述译文

恢复期间，当所有来源（pg_wal、归档或流式传输）均无 WAL 数据可用时等待。

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

触发机制

WAIT_EVENT_RECOVERY_RETRIEVE_RETRY_INTERVAL 位于 src/backend/access/transam/xlogrecovery.c:3764，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:179。探针覆盖的操作是：恢复期间，当所有来源（pg_wal、归档或流式传输）均无 WAL 数据可用时等待。RecoveryRetrieveRetryInterval 路径有意等待计时器、重试间隔、节流或安全退避；latch 超时后才重新评估工作。

正常还是麻烦？

正常: 当配置策略是有意的，而且有效工作按预期速率推进时，这项等待正常。
需要调查: 策略导致维护、恢复、备份或延迟目标无法达成，或者 spin delay 持续时，应当调查。

诊断 SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
  AND wait_event = 'RecoveryRetrieveRetryInterval'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'RecoveryRetrieveRetryInterval'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

确认拥有该计时器的 GUC 或函数。
比较有效工作量与延迟时间。
先检查它原本要控制的 CPU、I/O 与持久性压力，再调整策略。

源码证据

PostgreSQL 18.6 · src/backend/access/transam/xlogrecovery.c:3764 — WAIT_EVENT_RECOVERY_RETRIEVE_RETRY_INTERVAL
PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:179 — RECOVERY_RETRIEVE_RETRY_INTERVAL

GUC: 无直接关联项。
指标: [metric:waiting_sessions] · [metric:wait_event_share]

6 - Timeout: RegisterSyncRequest

由于请求队列已满，在向 checkpointer 发送同步请求时等待。

PostgreSQL 等待事件档案

类别Timeout 事件RegisterSyncRequest 版本PG 13-18 证据2 个源码位置

官方描述译文

由于请求队列已满，在向 checkpointer 发送同步请求时等待。

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

触发机制

WAIT_EVENT_REGISTER_SYNC_REQUEST 位于 src/backend/storage/sync/sync.c:615，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:180。探针覆盖的操作是：由于请求队列已满，在向 checkpointer 发送同步请求时等待。RegisterSyncRequest 路径有意等待计时器、重试间隔、节流或安全退避；latch 超时后才重新评估工作。

正常还是麻烦？

正常: 当配置策略是有意的，而且有效工作按预期速率推进时，这项等待正常。
需要调查: 策略导致维护、恢复、备份或延迟目标无法达成，或者 spin delay 持续时，应当调查。

诊断 SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
  AND wait_event = 'RegisterSyncRequest'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'RegisterSyncRequest'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

确认拥有该计时器的 GUC 或函数。
比较有效工作量与延迟时间。
先检查它原本要控制的 CPU、I/O 与持久性压力，再调整策略。

源码证据

PostgreSQL 18.6 · src/backend/storage/sync/sync.c:615 — WAIT_EVENT_REGISTER_SYNC_REQUEST
PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:180 — REGISTER_SYNC_REQUEST

GUC: 无直接关联项。
指标: [metric:waiting_sessions] · [metric:wait_event_share]

7 - Timeout: SpinDelay

获取发生争用的 spinlock 时等待。

PostgreSQL 等待事件档案

类别Timeout 事件SpinDelay 版本PG 16-18 证据2 个源码位置

官方描述译文

获取发生争用的 spinlock 时等待。

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

触发机制

WAIT_EVENT_SPIN_DELAY 位于 src/backend/storage/lmgr/s_lock.c:148，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:181。探针覆盖的操作是：获取发生争用的 spinlock 时等待。SpinDelay 路径有意等待计时器、重试间隔、节流或安全退避；latch 超时后才重新评估工作。

正常还是麻烦？

正常: 当配置策略是有意的，而且有效工作按预期速率推进时，这项等待正常。
需要调查: 策略导致维护、恢复、备份或延迟目标无法达成，或者 spin delay 持续时，应当调查。

诊断 SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
  AND wait_event = 'SpinDelay'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'SpinDelay'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

确认拥有该计时器的 GUC 或函数。
比较有效工作量与延迟时间。
先检查它原本要控制的 CPU、I/O 与持久性压力，再调整策略。

源码证据

PostgreSQL 18.6 · src/backend/storage/lmgr/s_lock.c:148 — WAIT_EVENT_SPIN_DELAY
PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:181 — SPIN_DELAY

GUC: 无直接关联项。
指标: [metric:waiting_sessions] · [metric:wait_event_share]

8 - Timeout: VacuumDelay

在基于成本的 vacuum 延迟点等待。

PostgreSQL 等待事件档案

类别Timeout 事件VacuumDelay 版本PG 13-18 证据2 个源码位置

官方描述译文

在基于成本的 vacuum 延迟点等待。

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

触发机制

WAIT_EVENT_VACUUM_DELAY 位于 src/backend/commands/vacuum.c:2495，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:182。探针覆盖的操作是：在基于成本的 vacuum 延迟点等待。VacuumDelay 路径有意等待计时器、重试间隔、节流或安全退避；latch 超时后才重新评估工作。

正常还是麻烦？

正常: 当配置策略是有意的，而且有效工作按预期速率推进时，这项等待正常。
需要调查: 策略导致维护、恢复、备份或延迟目标无法达成，或者 spin delay 持续时，应当调查。

诊断 SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
  AND wait_event = 'VacuumDelay'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'VacuumDelay'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

确认拥有该计时器的 GUC 或函数。
比较有效工作量与延迟时间。
先检查它原本要控制的 CPU、I/O 与持久性压力，再调整策略。

源码证据

PostgreSQL 18.6 · src/backend/commands/vacuum.c:2495 — WAIT_EVENT_VACUUM_DELAY
PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:182 — VACUUM_DELAY

GUC: [guc:autovacuum_naptime]
指标: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:oldest_transaction_age]

9 - Timeout: VacuumTruncate

等待获取独占锁，以截去正在执行 vacuum 的表末尾所有空页。

PostgreSQL 等待事件档案

类别Timeout 事件VacuumTruncate 版本PG 15-18 证据2 个源码位置

官方描述译文

等待获取独占锁，以截去正在执行 vacuum 的表末尾所有空页。

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

触发机制

WAIT_EVENT_VACUUM_TRUNCATE 位于 src/backend/access/heap/vacuumlazy.c:3280，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:183。探针覆盖的操作是：等待获取独占锁，以截去正在执行 vacuum 的表末尾所有空页。VacuumTruncate 路径有意等待计时器、重试间隔、节流或安全退避；latch 超时后才重新评估工作。

正常还是麻烦？

正常: 当配置策略是有意的，而且有效工作按预期速率推进时，这项等待正常。
需要调查: 策略导致维护、恢复、备份或延迟目标无法达成，或者 spin delay 持续时，应当调查。

诊断 SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
  AND wait_event = 'VacuumTruncate'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'VacuumTruncate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

确认拥有该计时器的 GUC 或函数。
比较有效工作量与延迟时间。
先检查它原本要控制的 CPU、I/O 与持久性压力，再调整策略。

源码证据

PostgreSQL 18.6 · src/backend/access/heap/vacuumlazy.c:3280 — WAIT_EVENT_VACUUM_TRUNCATE
PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:183 — VACUUM_TRUNCATE

GUC: [guc:autovacuum_naptime]
指标: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:oldest_transaction_age]

10 - Timeout: WalSummarizerError

WAL summarizer 出错后等待。

PostgreSQL 等待事件档案

类别Timeout 事件WalSummarizerError 版本PG 17-18 证据2 个源码位置

官方描述译文

WAL summarizer 出错后等待。

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

触发机制

WAIT_EVENT_WAL_SUMMARIZER_ERROR 位于 src/backend/postmaster/walsummarizer.c:337，是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:184。探针覆盖的操作是：WAL summarizer 出错后等待。WalSummarizerError 路径有意等待计时器、重试间隔、节流或安全退避；latch 超时后才重新评估工作。

正常还是麻烦？

正常: 当配置策略是有意的，而且有效工作按预期速率推进时，这项等待正常。
需要调查: 策略导致维护、恢复、备份或延迟目标无法达成，或者 spin delay 持续时，应当调查。

诊断 SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
  AND wait_event = 'WalSummarizerError'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
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 = 'Timeout'
  AND a.wait_event = 'WalSummarizerError'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

确认拥有该计时器的 GUC 或函数。
比较有效工作量与延迟时间。
先检查它原本要控制的 CPU、I/O 与持久性压力，再调整策略。

源码证据

PostgreSQL 18.6 · src/backend/postmaster/walsummarizer.c:337 — WAIT_EVENT_WAL_SUMMARIZER_ERROR
PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:184 — WAL_SUMMARIZER_ERROR

GUC: [guc:wal_buffers] · [guc:synchronous_commit]
指标: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:wal_bytes] · [metric:wal_write_time]

Timeout 等待

找到策略责任方

值得先认出的事件

常见误读

1 - Timeout: BaseBackupThrottle

官方描述译文

触发机制

正常还是麻烦？

诊断 SQL

处置建议

源码证据

关联控制项与信号

2 - Timeout: CheckpointWriteDelay

官方描述译文

触发机制

正常还是麻烦？

诊断 SQL

处置建议

源码证据

关联控制项与信号

3 - Timeout: PgSleep

官方描述译文

触发机制

正常还是麻烦？

诊断 SQL

处置建议

源码证据

关联控制项与信号

4 - Timeout: RecoveryApplyDelay

官方描述译文

触发机制

正常还是麻烦？

诊断 SQL

处置建议

源码证据

关联控制项与信号

5 - Timeout: RecoveryRetrieveRetryInterval

官方描述译文

触发机制

正常还是麻烦？

诊断 SQL

处置建议

源码证据

关联控制项与信号

6 - Timeout: RegisterSyncRequest

官方描述译文

触发机制

正常还是麻烦？

诊断 SQL

处置建议

源码证据

关联控制项与信号

7 - Timeout: SpinDelay

官方描述译文

触发机制

正常还是麻烦？

诊断 SQL

处置建议

源码证据

关联控制项与信号

8 - Timeout: VacuumDelay

官方描述译文

触发机制

正常还是麻烦？

诊断 SQL

处置建议

源码证据

关联控制项与信号

9 - Timeout: VacuumTruncate

官方描述译文

触发机制

正常还是麻烦？

诊断 SQL

处置建议

源码证据

关联控制项与信号

10 - Timeout: WalSummarizerError

官方描述译文

触发机制

正常还是麻烦？