# 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 {#identity}

| Field | Value | Meaning |
| --- | --- | --- |
| Type | `string` | Upstream pg_settings type |
| Context | `sighup` | Takes effect after configuration reload |
| Unit | — | Raw unit |
| Range | — | Raw limits in the last observed version |
| Enum values | — | — for non-enum types |
| Category | Replication / Primary Server | Upstream classification |
| Latest boot value | `""` | empty string |
{.fields meta="-"}

## Lifecycle {#lifecycle}

| Fact | Value |
| --- | --- |
| First observed | PG9.1 |
| Present in | PG9.1–19 Beta 3 |
| Removed in | No |
| Introduction commit | [`a8a8a3e09652`](https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a8a8a3e0965201df88bdfdff08f50e5c06c552b7) — 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 {#default-history}

| Versions | Raw `boot_val` | Unit | Human value |
| --- | --- | --- | --- |
| PG9.1–19 Beta 3 | `""` | — | empty string |
{.full-width caption="Measured PG9.0–19 Beta 3 boot defaults"}

## How it works {#mechanism}

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 {#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. |
{.full-width}

## Pigsty {#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 | — | — |
{.full-width}

> [!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 {#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.

## Related parameters {#related-parameters}

[`synchronous_commit`](/parameters/synchronous-commit/) · [`wal_sender_timeout`](/parameters/wal-sender-timeout/) · [`max_wal_senders`](/parameters/max-wal-senders/) · [`application_name`](/parameters/application-name/) · [`synchronized_standby_slots`](/parameters/synchronized-standby-slots/) · [`vacuum_defer_cleanup_age`](/parameters/vacuum-defer-cleanup-age/)

## References {#references}

- [PostgreSQL 19 Beta 3 — synchronous_standby_names](https://www.postgresql.org/docs/19/runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES)
- [PostgreSQL 19 release notes](https://www.postgresql.org/docs/19/release-19.html)
- [Machine-readable GUC export](/data/guc.jsonl)