Parameter · Reporting and Logging / What to Log
log_checkpoints
Logs each checkpoint.
- Default:
on - Type: bool
- Applies: Reload
In plain words
Writes two lines for every checkpoint: when it starts (and why), and when it completes with statistics. Default on since PostgreSQL 15; leave it on, it costs almost nothing and is invaluable when diagnosing I/O spikes.
For DBAs and operators
Real lines (18.6):
LOG: checkpoint starting: time LOG: checkpoint complete: wrote 10910 buffers (66.6%), wrote 1 SLRU buffers; 0 WAL file(s) added, 2 removed, 31 recycled; write=19.513 s, sync=1.077 s, total=20.818 s; sync files=345, longest=0.261 s, average=0.004 s; distance=542081 kB, estimate=542081 kB; lsn=0/44093938, redo lsn=0/24160870The start reason tells you a lot: time (checkpoint_timeout, good), wal (max_wal_size reached: too small for the write rate), immediate force wait (manual CHECKPOINT), shutdown immediate, end-of-recovery immediate wait. Restartpoints on a standby log restartpoint starting: ….
In the completion line: write should be close to checkpoint_timeout × checkpoint_completion_target for timed checkpoints; a large sync or longest points to storage that cannot absorb fsyncs; distance is WAL since the previous checkpoint (compare with max_wal_size). Frequent wal-triggered checkpoints also trigger LOG: checkpoints are occurring too frequently (N seconds apart) (see checkpoint_warning).
How to change it
Change in postgresql.conf or ALTER SYSTEM, then run SELECT pg_reload_conf().
See it in context
Checkpoints Checkpointer Server shutdown modes Crash recovery
Related parameters
checkpoint_timeout max_wal_size checkpoint_completion_target checkpoint_warning