synchronous_standby_names

synchronous_standby_names — Number of synchronous standbys and list of names of potential synchronous ones. Observed in PG9.1–19 Beta 3; its last measured boot default is empty string in PG19 Beta 3, with sighup context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Number of synchronous standbys and list of names of potential synchronous ones.”

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 / Primary Server: Upstream classification
Latest boot value , Value"": empty string

Lifecycle

Fact	Value
First observed	PG9.1
Present in	PG9.1–19 Beta 3
Removed in	No
Introduction commit	`a8a8a3e09652` — Efficient transaction-controlled synchronous replication. If a standby is broadcasting reply messages and we have named one or more standbys in synchronous_standby_names then allow users who set synchronous_replication to wait for commit, which then provides strict data integrity guarantees. Design avoids sending and receiving transaction state information so minimises bookkeeping overheads. We synchronize with the highest priority standby that is connected and ready to synchronize. Other standbys can be defined to takeover in case of standby failure.
Commit date	2011-03-06
Discussion	—

Default history

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

How it works

Number of synchronous standbys and list of names of potential synchronous ones. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

This parses priority FIRST or quorum ANY syntax over standby application_name values. It only defines eligible acknowledgers; synchronous_commit selects what each transaction waits for, and duplicate or wildcard names can make the chosen standby surprising.

Monitor and change synchronous_standby_names together with synchronous_commit, wal_sender_timeout, max_wal_senders. 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 synchronous_standby_names 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: PG9.1–19 Beta 3 unmodified; OLAP: PG9.1–19 Beta 3 unmodified; CRIT: PG9.1–19 Beta 3 unmodified; TINY: PG9.1–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Assuming the list alone makes every transaction synchronous.
Using duplicate application_name values and getting nondeterministic priority.
Choosing ANY/FIRST counts that cannot be satisfied during planned maintenance.
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.

synchronous_commit · wal_sender_timeout · max_wal_senders · application_name · synchronized_standby_slots · vacuum_defer_cleanup_age