synchronized_standby_slots

Definition PG 18 manual

A comma-separated list of streaming replication standby server slot names that logical WAL sender processes will wait for. Logical WAL sender processes will send decoded changes to plugins only after the specified replication slots confirm receiving WAL. This guarantees that logical replication failover slots do not consume changes until those changes are received and flushed to corresponding physical standbys. If a logical replication connection is meant to switch to a physical standby after the standby is promoted, the physical replication slot for the standby should be listed here. Note that logical replication will not proceed if the slots specified in the synchronized_standby_slots do not exist or are invalidated. Additionally, the replication management functions pg_replication_slot_advance, pg_logical_slot_get_changes, and pg_logical_slot_peek_changes, when used with logical failover slots, will block until all physical slots specified in synchronized_standby_slots have confirmed WAL receipt.

The standbys corresponding to the physical replication slots in synchronized_standby_slots must configure sync_replication_slots = true so they can receive logical failover slot changes from the primary.

How it works

Lists streaming replication standby server replication slot names that logical WAL sender processes will wait for. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

Logical senders on the primary wait until every listed physical standby slot has confirmed the relevant WAL before decoding sends changes. This protects failover-slot continuity, but a missing, invalid, or stalled listed slot can stop logical replication and slot-management functions.

Monitor and change synchronized_standby_slots together with sync_replication_slots, primary_slot_name, max_replication_slots. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Listing a missing or invalid slot and blocking logical senders.

Confusing physical slot names with standby application_name values.

Failing to enable sync_replication_slots on the corresponding standbys.

Changing it on the wrong primary, standby, sender, or subscriber role.

Watching only configured bytes/time instead of actual lag, slot position, and worker state.

Workload guidance

OLAP: Read standbys and logical subscribers often see long queries or large transactions. Put explicit bounds on replay/apply and monitor lag, worker saturation, slot restart_lsn, and conflict cancellations.

OLTP: Size synchronized_standby_slots from topology, failover roles, slot/subscription count, and reconnect headroom. Test worst-case primary latency, standby replay, and disk retention before production.

SMALL: Configure only replication capacity that is actually used. Even a small topology needs bounded timeouts and slot lifecycle; unlimited retention is not reliability.