log_checkpoints

Definition PG 18 manual

Causes checkpoints and restartpoints to be logged in the server log. Some statistics are included in the log messages, including the number of buffers written and the time spent writing them. This parameter can only be set in the postgresql.conf file or on the server command line. The default is on.

How it works

log_checkpoints logs each checkpoint. A checkpoint record includes elapsed phases and buffer or WAL work, exposing checkpoint cadence and write pressure rather than merely a marker.

log_checkpoints is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value.

It changes emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

Operational considerations

Editing log_checkpoints without reloading configuration and verifying the effective value and subsequent behavior.

Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.

Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.

Changing log_checkpoints globally without a rollback plan and a client or operational compatibility test.

Workload guidance

OLAP: Analytical jobs can justify richer log_checkpoints telemetry, but account for long statements, large bind values, and bursty completion patterns in the log pipeline.

OLTP: Tune log_checkpoints against an explicit observability question and a measured log-volume budget. Prefer selective thresholds, sampling, or role-level overrides over indiscriminate capture.

SMALL: Keep log_checkpoints useful but bounded: verify disk, collector, retention, and redaction capacity before increasing detail or frequency.