synchronous_commit

synchronous_commit — Sets the current transaction’s synchronization level. Observed in PG9.0–19 Beta 3; its last measured boot default is on in PG19 Beta 3, with user context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Sets the current transaction’s synchronization level.”

Identity

Type , Valueenum: Upstream pg_settings type
Context , Valueuser: Settable by an ordinary user
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Valuelocal, remote_write, remote_apply, on, off: — for non-enum types
Category , ValueWrite-Ahead Log / Settings: Upstream classification
Latest boot value , Valueon: on

Lifecycle

Fact	Value
First observed	PG9.0 (research boundary)
Present in	PG9.0–19 Beta 3
Removed in	No
Introduction commit	Not asserted: predates the PG9.0 research boundary
Commit date	—
Discussion	—

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG9.0–19 Beta 3	`on`	—	on

How it works

All modes except off wait for the transaction’s WAL to be flushed locally. With off, success can be returned before local durable flush; a crash can lose recent acknowledged transactions, but recovery remains transactionally consistent and does not introduce the corruption risk associated with fsync = off.

When synchronous_standby_names selects synchronous standbys, remote_write waits for receipt and an operating-system write on a standby, on waits for a durable standby flush, and remote_apply waits for replay and query visibility. local waits only for local durable flush. Without a selected synchronous standby, the remote modes add no remote guarantee.

The effective mode is the value in force when a transaction commits. Applications can use SET LOCAL for one transaction, allowing critical and replaceable work to use different durability policies on the same server.

Tuning advice

Tip

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

Workload	Guidance
OLTP	Keep on as the general default. Use off only for explicitly replaceable transactions, and use remote_apply only when post-commit reads on a synchronous standby require causal visibility; include network round-trip and standby health in the latency budget.
OLAP	For a reproducible bulk load, transaction-local off can improve throughput if losing the final unflushed portion is acceptable and the load can be rerun. Keep catalog changes, handoff markers, and externally visible completion records synchronous.
Small nodes	Retain on. Small systems rarely gain enough from a global durability downgrade to justify the operational ambiguity; tune individual noncritical jobs instead.

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

Common pitfalls

Equating synchronous_commit = off with fsync = off; the former risks recent data loss, not structural corruption.
Expecting remote_write, on, or remote_apply to wait remotely when no synchronous standby is selected.
Using remote_write while assuming the standby is durable across an operating-system crash.
Allowing an unavailable synchronous standby to stall commits without an HA response plan.
Leaking a session-level SET through a connection pool instead of using SET LOCAL or reset discipline.

synchronous_standby_names · fsync · wal_writer_delay · wal_sync_method · commit_delay · wal_level