Wiki / Configuration Parameters
data_sync_retry
When set to off, which is the default, PostgreSQL will raise a PANIC-level error on failure to flush modified data files to the file system. This causes the database server to crash. This parameter can only be set at server start. On some operating systems, the status of data in the kernel's page cache is unknown after a write-back failure. In some cases it might have been entirely forgotten, making it unsafe to retry; the second attempt may be reported as successful, when in fact the data has been lost. In these circumstances, the only way to avoid data loss is to recover from the WAL after any failure is reported, preferably after investigating the root cause of the failure and replacing any faulty hardware. If set to on, PostgreSQL will instead report an error but continue to run so that the data flushing operation can be retried in a later checkpoint. Only set it to on after investigating the operating system's treatment of buffered data in case of write-back failure.
English manual coverage begins with PostgreSQL 7.4. Source history and runtime observations have their own recorded version boundaries.
Reading PG 18·Select a recorded version
- boot val
- off
- category
- Error Handling
- context
- postmaster
- documented
- true
- enumvals
- Unknown
- extra desc
- Unknown
- lang
- en
- max val
- Unknown
- metadata version
- 18
- min val
- Unknown
- name
- data_sync_retry
- short desc
- Whether to continue running after a failure to sync data files.
- source
- pg-settings-source-snapshot
- unit
- Unknown
- vartype
- bool
Definition PG 18
When set to off, which is the default, PostgreSQL will raise a PANIC-level error on failure to flush modified data files to the file system. This causes the database server to crash. This parameter can only be set at server start. On some operating systems, the status of data in the kernel's page cache is unknown after a write-back failure. In some cases it might have been entirely forgotten, making it unsafe to retry; the second attempt may be reported as successful, when in fact the data has been lost. In these circumstances, the only way to avoid data loss is to recover from the WAL after any failure is reported, preferably after investigating the root cause of the failure and replacing any faulty hardware. If set to on, PostgreSQL will instead report an error but continue to run so that the data flushing operation can be retried in a later checkpoint. Only set it to on after investigating the operating system's treatment of buffered data in case of write-back failure.
Compare versions
Source references
Full definition and evidence JSON
Definition sources
center · PostgreSQL 18 · wiki-repair-20261023:29a41c41144e2e5602b1dceb5e19170ab7f3420c16793ca813ddc05aff9d0e82
Text language: en · wiki-repair-20261023:29a41c41144e2e5602b1dceb5e19170ab7f3420c16793ca813ddc05aff9d0e82