wal_keep_segments

wal_keep_segments — Sets the number of WAL files held for standby servers. Observed in PG9.0–12; its last measured boot default is 0 in PG12, with sighup context. It was removed in PG13.

Note

Fact — official short description: “Sets the number of WAL files held for standby servers.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valuesighup: Takes effect after configuration reload
Unit , Value—: Raw unit
Range , Value0 – 2147483647: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueReplication / Sending Servers: Upstream classification
Latest boot value , Value0: 0

Lifecycle

Fact	Value
First observed	PG9.0 (research boundary)
Present in	PG9.0–12
Removed in	PG13
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–12	`0`	—	0

How it works

Sets the number of WAL files held for standby servers. The parameter still exists in PG12 and is no longer recognized from PG13. PostgreSQL 13 replaced the segment-count interface with wal_keep_size, which expresses the retention floor in bytes rather than assuming a segment size.

This retained at least a count of old WAL segments for lagging standbys, so its byte effect changed with wal_segment_size. It was only a floor—not protection from every retention/removal condition—and PostgreSQL 13 replaced it with wal_keep_size.

Before upgrading, inspect wal_keep_size, wal_segment_size, max_slot_wal_keep_size, remove the old name from configuration, ALTER SYSTEM, role/database settings, and automation templates, and verify the replacement before starting PG13 or later.

Tuning advice

Tip

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

Workload	Guidance
OLTP	Do not tune or continue emitting wal_keep_segments on PG13+. PostgreSQL 13 replaced the segment-count interface with wal_keep_size, which expresses the retention floor in bytes rather than assuming a segment size. Scan every configuration layer and regression-test the application before upgrade.
OLAP	Use the same migration path as OLTP, and also verify long batches, standbys, or large-object/extension workflows; removal of the old switch does not promise identical legacy behavior.
Small nodes	Delete the obsolete setting and adopt the supported replacement directly; do not emulate legacy behavior in scripts without a demonstrated compatibility requirement.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG12; 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–12 unmodified; OLAP: PG9.0–12 unmodified; CRIT: PG9.0–12 unmodified; TINY: PG9.0–12 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Copying the old integer directly to wal_keep_size without multiplying by wal_segment_size.
Treating the retained count as a maximum rather than a minimum floor.
Leaving the removed name in PG13+ automation.
Continuing to emit unknown parameter wal_keep_segments on PG13+.
Deleting only the setting name without migrating dependent application behavior.

wal_keep_size · wal_segment_size · max_slot_wal_keep_size · max_wal_size · primary_slot_name · idle_replication_slot_timeout