max_repack_replication_slots

max_repack_replication_slots — Sets the maximum number of replication slots for use by REPACK. Observed in PG19 Beta 3; its last measured boot default is 5 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 replication slots for use by REPACK.”

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 , Value5: 5

Lifecycle

Fact	Value
First observed	PG19 Beta 3
Present in	PG19 Beta 3
Removed in	No
Introduction commit	`e76d8c749c31` — Reserve replication slots specifically for REPACK
Commit date	2026-04-07
Discussion	thread 1

Default history

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

How it works

PostgreSQL describes max_repack_replication_slots as follows: “Sets the maximum number of replication slots for use by REPACK.” The value is fixed when the server starts, so changing it requires a controlled restart. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

PostgreSQL 19’s REPACK command can use dedicated replication slots to reorganize a relation concurrently while tracking changes. This startup ceiling reserves how many such slots the server can support; it interacts with the overall replication-slot and WAL-sender budgets and with retained-WAL disk risk.

Read it together with max_replication_slots, max_wal_senders, wal_level, max_slot_wal_keep_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	Model normal failover and worst-case lag before setting a bound. Observe sender state, retained WAL, shutdown time, and receiver catch-up; preserve enough capacity for monitoring and planned switchovers.
OLAP	Account for large transactions, bulk loads, slow apply, and long-distance links. A short timeout can make shutdown faster but transfer recovery work and inconsistency risk to the next startup.
Small nodes	Use few slots and senders, watch pg_wal disk consumption, and keep timeout behavior explicit. Test shutdown and restart with the receiver both healthy and unavailable.

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	Unmodified	—	—
OLAP	Unmodified	—	—
CRIT	Unmodified	—	—
TINY	Unmodified	—	—

Caution

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

Common pitfalls

Treating the measured boot_val for max_repack_replication_slots as proof of the effective value on an initialized or managed cluster.
Applying a change as though it were immediate while pg_settings reports postmaster context.
Changing this setting in isolation without checking the linked limits, observability, and rollback path.
Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

max_replication_slots · max_wal_senders · wal_level · max_slot_wal_keep_size · wal_sender_shutdown_timeout