select open change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

CONFIGURATION / WRITE-AHEAD LOG

checkpoint_segments

Read PG 9.4 manual ↗

Maximum number of log file segments between automatic WAL checkpoints (each segment is normally 16 megabytes).

Historical documentation for a PostgreSQL version that is no longer supported.

Type
integer
Context
sighup
Measured default
3
Unit
Metadata snapshot
9.4

Definition PG 9.4 manual

Maximum number of log file segments between automatic WAL checkpoints (each segment is normally 16 megabytes). The default is three segments. Increasing this parameter can increase the amount of time needed for crash recovery. This parameter can only be set in the postgresql.conf file or on the server command line.

Measured default history
Version intervalDefault
9.0 – 9.43
Analysis & operational context

Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗

How it works

PostgreSQL describes checkpoint_segments as follows: “Sets the maximum distance in log segments between automatic WAL checkpoints.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG9.0–9.4; boot_val is the compiled or initialized baseline, not proof of a running cluster's effective setting.

This was the pre-9.5 checkpoint volume control: once accumulated WAL approached the configured number of segments, PostgreSQL requested an automatic checkpoint. PostgreSQL 9.5 replaced it with max_wal_size, whose soft byte-size budget works with checkpoint_timeout and checkpoint_completion_target rather than exposing a segment count.

Read it together with max_wal_size, checkpoint_timeout, checkpoint_completion_target, wal_segment_size. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Operational considerations

Treating the measured boot_val for checkpoint_segments as proof of the effective value on an initialized or managed cluster.

Applying a change as though it were immediate while pg_settings reports sighup context.

Changing this setting in isolation without checking the linked limits, observability, and rollback path.

Copying the removed name into a modern postgresql.conf instead of migrating to its documented successor.

Workload guidance

OLAP: For an upgrade or analytical estate, inventory every generated configuration before cutover. Map the old control to its successor and compare plans, throughput, WAL, or logging behavior rather than assuming the old numeric value is portable.

OLTP: Do not add this retired name to a current OLTP configuration. Translate its intent to the documented successor, test the migration under connection and write concurrency, and remove stale automation that still emits it.

SMALL: Delete the obsolete override after recording why it existed. On a small node, prefer the successor's default until measurements justify a new value; an unknown startup parameter can otherwise stop the server.

Version history 1
  1. PG 9.4 → 9.5removed

Related entries

Further reading

Definition snapshot: english-manuals:f2e715052a3be0fe42ecbebd307… · English manual source