Parameter · Error Handling
data_sync_retry
Whether to continue running after a failure to sync data files.
- Default:
off - Type: bool
- Applies: Restart required
In plain words
When the operating system reports that it could not write a data file to disk (fsync failed), PostgreSQL cannot be sure the data is on disk, and on Linux the failed pages may have been silently discarded. With the default off, PostgreSQL deliberately crashes (PANIC) and replays WAL, which rewrites the data correctly. With on it reports an error and tries again at the next checkpoint.
Leave it off unless you know your storage keeps dirty data after a failed fsync.
For DBAs and operators
Background: the 2018 "fsyncgate" discovery showed that Linux may mark dirty pages clean after a failed write-back, so a later successful fsync proves nothing. Since then (11.2, 10.7, … and all later releases) PostgreSQL PANICs:
PANIC: could not fsync file "base/16384/16397": Input/output error
The server restarts (if restart_after_crash is on) and crash recovery rewrites every change since the last checkpoint from WAL, which is still intact. If the I/O error persists, the server will PANIC again: fix the storage first (dmesg, SMART, multipath, NFS/thin-provisioning out of space).
With on, the failure is reported at ERROR level and the checkpoint is retried, which is only safe on systems that keep dirty data after an fsync error. WAL fsync failures always PANIC regardless.
Repeated fsync PANICs in a log are a storage incident, not a PostgreSQL bug: thin-provisioned volumes running out of space are a frequent cause.
How to change it
Change in postgresql.conf or ALTER SYSTEM, then restart the server.