checkpoint_warning

Definition PG 18 manual

Write a message to the server log if checkpoints caused by the filling of WAL segment files happen closer together than this amount of time (which suggests that max_wal_size ought to be raised). If this value is specified without units, it is taken as seconds. The default is 30 seconds (30s). Zero disables the warning. No warnings will be generated if checkpoint_timeout is less than checkpoint_warning. This parameter can only be set in the postgresql.conf file or on the server command line.

How it works

Sets the maximum time before warning if checkpoints triggered by WAL volume happen too frequently. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

This parameter only emits a log warning when WAL-volume checkpoints occur closer together than the threshold. It does not delay checkpoints; frequent warnings normally point to max_wal_size being too small for the WAL generation rate.

Monitor and change checkpoint_warning together with checkpoint_flush_after, checkpoint_timeout, checkpoint_completion_target. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Treating the warning threshold as a control that delays or throttles checkpoints.

Setting zero and silencing evidence of WAL-volume checkpoints.

Raising the threshold instead of investigating WAL rate, max_wal_size, and requested-checkpoint frequency.

Setting checkpoint_warning above checkpoint_timeout and expecting time-based checkpoints to produce this warning.

Workload guidance

OLAP: Provision WAL, archive bandwidth, and recovery I/O for bulk-load peaks. Coordinate load pacing and checkpoints when reducing spikes; never break the recovery chain for throughput.

OLTP: Establish durability and recovery objectives first, then tune checkpoint_warning from WAL rate, flush latency, checkpoints, and peak pg_wal usage. Validate every change with crash/recovery and archive monitoring.

SMALL: Start from safe defaults and set explicit alerts for limited disk capacity. Do not disable durability or break the recovery chain merely to save modest I/O.