primary_conninfo

primary_conninfo sets the connection string to be used to connect to 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 connection string to be used to connect to 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 connection string to be used to connect to the sending server. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

The WAL receiver uses this libpq connection string to reach an upstream sender. Reloading a changed nonempty value restarts the receiver; credentials should come from a protected passfile where possible, and slot synchronization additionally requires dbname.

Monitor and change primary_conninfo together with max_wal_senders, max_replication_slots, wal_level. 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_conninfo 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

Embedding a plaintext password in broadly readable configuration or process diagnostics.
Omitting dbname when slot synchronization needs it.
Changing upstream identity without coordinating timeline and slot state.
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.

max_wal_senders · max_replication_slots · wal_level · wal_sender_timeout · max_slot_wal_keep_size · primary_slot_name