Timeout 等待
有意休眠、重试间隔、节流与限速延迟。
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 正常只会被持有极短时间。
基础备份期间，因限速而等待。
执行检查点时，在两次写入之间等待。
因调用 pg_sleep 或同类函数而等待。
恢复期间，因延迟设置而等待应用 WAL。
恢复期间，当所有来源（pg_wal、归档或流式传输）均无 WAL 数据可用时等待。
由于请求队列已满，在向 checkpointer 发送同步请求时等待。
获取发生争用的 spinlock 时等待。
在基于成本的 vacuum 延迟点等待。
等待获取独占锁，以截去正在执行 vacuum 的表末尾所有空页。
WAL summarizer 出错后等待。