# Timeout 等待

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

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

## 找到策略责任方 {#how-to-read}

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

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

## 值得先认出的事件 {#top-events}

| 事件 | 策略 |
| --- | --- |
| [VacuumDelay](vacuum-delay/) | 基于成本的 vacuum 节流 |
| [CheckpointWriteDelay](checkpoint-write-delay/) | 把检查点写入摊平到整个间隔 |
| [RecoveryApplyDelay](recovery-apply-delay/) | 有意延迟备库回放 |
| [RecoveryRetrieveRetryInterval](recovery-retrieve-retry-interval/) | 对不可用 WAL 源进行重试 |
| [BaseBackupThrottle](base-backup-throttle/) | 备份传输限速 |
| [PgSleep](pg-sleep/) | SQL 或内部 sleep 函数 |
| [SpinDelay](spin-delay/) | 获取竞争 spinlock 时退避 |

## 常见误读 {#misreads}

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

---

本节页面：

- [Timeout: BaseBackupThrottle](/zh/timeout/base-backup-throttle/): 基础备份期间，因限速而等待。
- [Timeout: CheckpointWriteDelay](/zh/timeout/checkpoint-write-delay/): 执行检查点时，在两次写入之间等待。
- [Timeout: PgSleep](/zh/timeout/pg-sleep/): 因调用 pg_sleep 或同类函数而等待。
- [Timeout: RecoveryApplyDelay](/zh/timeout/recovery-apply-delay/): 恢复期间，因延迟设置而等待应用 WAL。
- [Timeout: RecoveryRetrieveRetryInterval](/zh/timeout/recovery-retrieve-retry-interval/): 恢复期间，当所有来源（pg_wal、归档或流式传输）均无 WAL 数据可用时等待。
- [Timeout: RegisterSyncRequest](/zh/timeout/register-sync-request/): 由于请求队列已满，在向 checkpointer 发送同步请求时等待。
- [Timeout: SpinDelay](/zh/timeout/spin-delay/): 获取发生争用的 spinlock 时等待。
- [Timeout: VacuumDelay](/zh/timeout/vacuum-delay/): 在基于成本的 vacuum 延迟点等待。
- [Timeout: VacuumTruncate](/zh/timeout/vacuum-truncate/): 等待获取独占锁，以截去正在执行 vacuum 的表末尾所有空页。
- [Timeout: WalSummarizerError](/zh/timeout/wal-summarizer-error/): WAL summarizer 出错后等待。