primary_slot_name

primary_slot_name sets the name of the replication slot to use on the sending server. It is a sighup setting present in PG12–18; the latest recorded boot default is empty.

Note

Fact — official short description: “Sets the name of the replication slot to use on the sending server.”

Identity

Type , Valuestring: 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 , Value"": empty string

Lifecycle

Fact	Value
First observed	PG12
Present in	PG12–19 Beta 3
Removed in	No
Introduction commit	`2dedf4d9a899` — Integrate recovery.conf into postgresql.conf
Commit date	2018-11-25
Discussion	thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG12–19 Beta 3	`""`	—	empty string

How it works

Sets the name of the replication slot to use on the sending server. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

The receiver names an existing upstream physical slot so the sender retains WAL needed by this standby. It improves continuity across disconnects but transfers disk-retention risk to the primary and must match slot lifecycle during failover.

Monitor and change primary_slot_name together with wal_keep_segments, wal_keep_size, wal_segment_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 primary_slot_name 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: PG12–19 Beta 3 unmodified; OLAP: PG12–19 Beta 3 unmodified; CRIT: PG12–19 Beta 3 unmodified; TINY: PG12–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Creating a slot without monitoring restart_lsn and primary disk usage.
Dropping or reusing the slot during failover without proving consumer position.
Assuming a slot alone archives or backs up WAL.
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.

wal_keep_segments · wal_keep_size · wal_segment_size · max_slot_wal_keep_size · max_wal_size · idle_replication_slot_timeout