Skip to content

wal_receiver_create_temp_slot

wal_receiver_create_temp_slot sets whether a WAL receiver should create a temporary replication slot if no permanent slot is configured. It is a sighup setting present in PG13–18; the latest recorded boot default is off.
Note

Fact — official short description: “Sets whether a WAL receiver should create a temporary replication slot if no permanent slot is configured.”

Identity

Type , Valuebool
Upstream pg_settings type
Context , Valuesighup
Takes effect after configuration reload
Unit , Value
Raw unit
Range , Value
Raw limits in the last observed version
Enum values , Value
— for non-enum types
Category , ValueReplication / Standby Servers
Upstream classification
Latest boot value , Valueoff
off

Lifecycle

Fact Value
First observed PG13
Present in PG13–19 Beta 3
Removed in No
Introduction commit 329730827848 — walreceiver uses a temporary replication slot by default
Commit date 2020-01-14
Discussion thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions Raw boot_val Unit Human value
PG13–19 Beta 3 off off

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.

Tuning advice

Tip

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

Workload Guidance
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.
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.
Small nodes Configure only replication capacity that is actually used. Even a small topology needs bounded timeouts and slot lifecycle; unlimited retention is not reliability.

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: PG13–19 Beta 3 unmodified; OLAP: PG13–19 Beta 3 unmodified; CRIT: PG13–19 Beta 3 unmodified; TINY: PG13–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

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

primary_slot_name · max_replication_slots · max_slot_wal_keep_size · wal_keep_size · hot_standby · hot_standby_feedback

References