Timeout waits

Timeout usually means PostgreSQL intentionally delayed work until a timer expires. The important question is not “why is the kernel slow?” but “which policy or safety mechanism inserted this delay?”

Identify the policy owner

Vacuum cost delay, recovery delay, backup throttling, checkpoint spreading, retry intervals, and pg_sleep() are designed waits. They become a problem when the policy no longer matches the service objective or when another bottleneck makes the delay recur excessively.

• Normal: the configured policy is active and useful work advances at the expected rate.
• Watch: foreground latency includes a deliberate sleep, or maintenance falls behind while spending much of its time throttled.
• Urgent: recovery/backup/checkpoint deadlines are missed, a spin delay persists, or an operator did not intend the policy.

Events to recognize

Common misreads

• Timeout does not mean a statement or lock timeout fired; it means the process is currently sleeping on a timer.
• Reducing vacuum delay can recover maintenance throughput but also increase I/O and CPU pressure.
• RecoveryApplyDelay can be intentional disaster-recovery policy.
• Persistent SpinDelay deserves escalation: a spinlock should normally be held for an extremely short time.