wal_receiver_create_temp_slot

Definition PG 18 manual

Specifies whether the WAL receiver process should create a temporary replication slot on the remote instance when no permanent replication slot to use has been configured (using primary_slot_name). The default is off. This parameter can only be set in the postgresql.conf file or on the server command line. If this parameter is changed while the WAL receiver process is running, that process is signaled to shut down and expected to restart with the new setting.

How it works

Sets whether a WAL receiver should create a temporary replication slot if no permanent slot is configured. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

If primary_slot_name is empty, the receiver can create a temporary upstream slot for the lifetime of its connection. That prevents removal during the connection but vanishes on disconnect, so it cannot guarantee catch-up across an outage.

Monitor and change wal_receiver_create_temp_slot together with primary_slot_name, max_replication_slots, max_slot_wal_keep_size. 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

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.

Failing over to a node that lacks the old primary's capacity or prerequisites.

Using infinite waits or WAL retention to hide a failed consumer.

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 wal_receiver_create_temp_slot 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.