max_repack_replication_slots

Definition PG 20 devel manual

Specifies the maximum number of replication slots for use of the REPACK command. The default is 5. This parameter can only be set at server start.

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.

Operational considerations

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.

Workload guidance

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.

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.

SMALL: 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.