Checkpoint counters matter when sampled as deltas and joined to foreground latency.
PostgreSQL Checkpoint Pressure
Checkpoint tuning is an I/O budget shared with foreground transactions and recovery.
SELECT now() AS sampled_at,
num_timed, num_requested,
write_time, sync_time, buffers_written
FROM pg_stat_checkpointer;
-- Store samples and alert on deltas, not lifetime totals:
-- requested/timed ratio -> WAL pressure
-- sync_time/checkpoints -> durability-path latency
-- correlate with WAL bytes, disk latency, p99, and replica lag.Invariant: Checkpoint rate and duration remain inside the tested foreground-latency and disk-headroom budget.
Use when: You need to distinguish WAL pressure from a slow durability path.
Why this boundary matters
Requested checkpoints and long sync phases can turn durability work into tail latency. Counter deltas distinguish WAL pressure from storage latency.
Failure policy
| Boundary | Action |
|---|---|
| Requested checkpoints rising | Inspect WAL rate before changing capacity |
| Write time high | Correlate dirty-page volume with storage throughput |
| Sync time high | Investigate durability-path latency |
| Archiving or slot stalled | Protect disk headroom before tuning cadence |
| Bulk operation planned | Rate-limit it against an I/O budget |
Trade-offs
Larger WAL budgets reduce checkpoint frequency but reserve more disk and can extend crash recovery. Pacing cannot compensate for an unstable storage path.
Decision rule: Change checkpoint controls only from measured WAL rate, storage latency, disk headroom, and a tested recovery objective.