max_replication_slots

max_replication_slots — Sets the maximum number of simultaneously defined replication slots. Observed in PG9.4–19 Beta 3; its last measured boot default is 10 in PG19 Beta 3, with postmaster context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Sets the maximum number of simultaneously defined replication slots.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valuepostmaster: Requires a server restart
Unit , Value—: Raw unit
Range , Value0 – 262143: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueReplication / Sending Servers: Upstream classification
Latest boot value , Value10: 10

Lifecycle

Fact	Value
First observed	PG9.4
Present in	PG9.4–19 Beta 3
Removed in	No
Introduction commit	`858ec11858a9` — Introduce replication slots.
Commit date	2014-01-31
Discussion	—

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG9.4–9.6	`0`	—	0
PG10–19 Beta 3	`10`	—	10

How it works

PostgreSQL allocates replication-slot control capacity at server start. Physical slots can reserve WAL for standbys, while logical slots can reserve both WAL and catalog visibility information for decoding consumers.

The setting limits slot objects, not active WAL-sender connections; max_wal_senders is a separate limit. Slot use also requires wal_level = replica or higher. Reducing the setting below the number of existing slots prevents the server from starting.

An unused slot is not harmless merely because it has no active process. A persistent inactive slot can retain WAL, and a logical slot can hold catalog_xmin, so slot inventory and consumer lifecycle are as important as the numerical ceiling.

Tuning advice

Tip

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

Workload	Guidance
OLTP	Budget slots from named physical standbys, logical subscriptions, CDC consumers, backup or migration tools, failover slots, and provisioning headroom. Keep a small reserve, but pair a larger ceiling with ownership, expiry, and lag monitoring.
OLAP	Allow for logical consumers and migration jobs, but remember that high-WAL batch periods magnify the cost of any abandoned slot. Monitor restart_lsn and confirmed_flush_lsn before and during bulk work.
Small nodes	Keep the ceiling close to the real consumer count plus limited reserve. A large value does not itself retain WAL, but it makes unmanaged slot sprawl easier and can turn a small disk incident into an outage.

Pigsty

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

Template	Effective value	Versus upstream boot	Source expression
OLTP	`50`	different	`50`
OLAP	`50`	different	`50`
CRIT	`50`	different	`50`
TINY	`50`	different	`50`

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.4–19 Beta 3 = 50 (dcs); OLAP: PG9.4–19 Beta 3 = 50 (dcs); CRIT: PG9.4–19 Beta 3 = 50 (dcs); TINY: PG9.4–19 Beta 3 = 50 (dcs). Advice, pending human review — confirm the operational intent against the current Pigsty templates and supported PostgreSQL versions before publication.

Common pitfalls

Confusing the slot limit with max_wal_senders, which limits concurrent sender processes.
Lowering the value below the current slot count and making PostgreSQL fail to start.
Assuming inactive slots cannot retain WAL or catalog row versions.
Raising the ceiling without monitoring restart_lsn, catalog_xmin, and consumer health.
Creating permanent slots during experiments and never dropping them.

max_wal_senders · max_slot_wal_keep_size · wal_level · idle_replication_slot_timeout · max_logical_replication_workers · primary_slot_name