checkpoint_segments

checkpoint_segments — Sets the maximum distance in log segments between automatic WAL checkpoints. Observed in PG9.0–9.4; its last measured boot default is 3 in PG9.4, with sighup context. It was removed in PG9.5.

Note

Fact — official short description: “Sets the maximum distance in log segments between automatic WAL checkpoints.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valuesighup: Takes effect after configuration reload
Unit , Value"": Raw unit
Range , Value1 – 2147483647: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueWrite-Ahead Log / Checkpoints: Upstream classification
Latest boot value , Value3: 3

Lifecycle

Fact	Value
First observed	PG9.0 (research boundary)
Present in	PG9.0–9.4
Removed in	PG9.5
Introduction commit	Not asserted: predates the PG9.0 research boundary
Commit date	—
Discussion	—

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG9.0–9.4	`3`	—	3

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.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
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.
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.
Small nodes	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.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG9.4; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	Unmodified	—	—
OLAP	Unmodified	—	—
CRIT	Unmodified	—	—
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–9.4 unmodified; OLAP: PG9.0–9.4 unmodified; CRIT: PG9.0–9.4 unmodified; TINY: PG9.0–9.4 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

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.

max_wal_size · checkpoint_timeout · checkpoint_completion_target · wal_segment_size · min_wal_size