data_sync_retry

data_sync_retry — Whether to continue running after a failure to sync data files. Observed in PG9.4–19 Beta 3; its last measured boot default is off in PG19 Beta 3, with postmaster context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Whether to continue running after a failure to sync data files.”

Identity

Type , Valuebool: Upstream pg_settings type
Context , Valuepostmaster: Requires a server restart
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueError Handling: Upstream classification
Latest boot value , Valueoff: off

Lifecycle

Fact	Value
First observed	PG9.4
Present in	PG9.4–19 Beta 3
Removed in	No
Introduction commit	`f1ff5f51d249` — PANIC on fsync() failure.
Commit date	2018-11-19
Discussion	thread 1

Default history

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

How it works

Whether to continue running after a failure to sync data files. The value is fixed when the server starts, so changing it requires a restart.

After a data-file fsync failure, the default behavior treats shared buffers as potentially inconsistent and raises PANIC so crash recovery re-establishes state. Continuing can lose knowledge of dirty pages and is intended only for platforms whose kernel semantics make retry safe.

Monitor and change data_sync_retry together with restart_after_crash, recovery_init_sync_method, fsync. Validate on the relevant server role and real workload, then use its postmaster 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	Change data_sync_retry only from an explicit failure model and measured evidence. Validate in a session/test environment, deploy according to its context, and retain a rollback value.
OLAP	Test separately under long queries, batch jobs, and peak concurrency rather than copying OLTP assumptions to analytical nodes.
Small nodes	Keep the default without a concrete problem; small systems should not trade global compatibility or failure semantics for a marginal gain.

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

Common pitfalls

Enabling it on a platform where fsync failure loses dirty-page knowledge.
Treating an I/O error as transient without replacing or fencing bad storage.
Optimizing availability at the expense of silent corruption.
Confusing the boot default of data_sync_retry with its current effective value.
Ignoring its postmaster context when deciding when it takes effect.

restart_after_crash · recovery_init_sync_method · fsync · full_page_writes · exit_on_error