{"Entry":{"collection":"guc","key":"data_sync_retry","name":"data_sync_retry","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Error Handling","category_zh":"","changed_in":[],"changes":[{"documentation_changed":false,"fields":{},"from":"9.3","status":"added","to":"9.4"},{"documentation_changed":true,"fields":{},"from":"11","status":"changed","to":"12"}],"content_hash":"a95180e966dfe0535234f4a3adca4bb48fc219ee89c858c8f24701692b703c2b","context":"","default_changed_in":[],"default_history":[{"from":"9.4","to":"19","value":"off"}],"derived_content_hash":"f2a811a102cc091a497ab61b6062891418708fff1fcb92c37fcd4459025b522b","editorial":{"advice":{"olap":"Test separately under long queries, batch jobs, and peak concurrency rather than copying OLTP assumptions to analytical nodes.","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.","small":"Keep the default without a concrete problem; small systems should not trade global compatibility or failure semantics for a marginal gain."},"mechanism":["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."],"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."],"references":[{"title":"PostgreSQL 19 Beta 4: data_sync_retry","url":"https://www.postgresql.org/docs/19/runtime-config-error-handling.html#GUC-DATA-SYNC-RETRY"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["restart_after_crash","recovery_init_sync_method","fsync","full_page_writes","exit_on_error"],"summary":"data_sync_retry — Whether to continue running after a failure to sync data files. Observed in PG9.4–19 Beta 4; its last measured boot default is off in PG19 Beta 4, with postmaster context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA."},"enumvals":[],"first_version":"9.4","group":"Error Handling","group_slug":"error-handling","imported_at":"2026-09-27T17:57:31.018186+08:00","intro_commit":{"authored_at":"2018-11-19T13:40:57+13:00","discussion":["https://postgr.es/m/20180427222842.in2e4mibx45zdth5%40alap3.anarazel.de"],"hash":"f1ff5f51d2490817c2b3bba202f4e2c73a846389","subject":"PANIC on fsync() failure.","url":"https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=f1ff5f51d2490817c2b3bba202f4e2c73a846389"},"key":"data_sync_retry","last_version":"20","max_val":"","min_val":"","name":"data_sync_retry","position":79,"present_in":["9.4","9.5","9.6","10","11","12","13","14","15","16","17","18","19","20"],"repair_provenance":{"original_source_revision":"english-manuals:5c7ae05ac2d0f1d627091faf898def28914f1d35ead6bf5e6cd6806e1c62436a","receipt_sha256":"b1bec85446abfe2d13313edcf0fd495e2412609c6d3364659862a3a705838030","repair":"wiki-repair-20261023"},"short_desc":"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.","short_desc_zh":"","source_rev":"wiki-repair-20261023:29a41c41144e2e5602b1dceb5e19170ab7f3420c16793ca813ddc05aff9d0e82","unit":"","vartype":"bool"}},"Definition":{"Collection":"guc","Key":"data_sync_retry","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"data_sync_retry","SourceRevision":"wiki-repair-20261023:29a41c41144e2e5602b1dceb5e19170ab7f3420c16793ca813ddc05aff9d0e82","Facts":{"boot_val":"off","category":"Error Handling","context":"postmaster","description":"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.","description_zh":"当设置为 off（默认值）时，PostgreSQL 在将修改后的数据文件刷盘到文件系统失败时，将引发 PANIC 级错误。这样会导致数据库服务器崩溃。这个参数只能在服务器启动时被设置。 在某些操作系统上，回写失败后，内核页面缓存中的数据状态未知。在某些情况下，它可能已被完全遗忘，因此重试不安全；第二次尝试可能报告为成功，而事实上数据已丢失。在此类情形下，避免数据丢失的唯一方法是在报告任何故障后从 WAL 中恢复，最好是在调查了故障的根本原因并更换了任何有故障的硬件之后。 如果设置为开（on），PostgreSQL 将报告错误，但会继续运行，以便可以在以后的检查点中重试数据刷盘操作。只有在调查清楚操作系统在回写失败时如何处理缓冲数据之后，才应将其设置为开（on）。","description_zh_html":"\u003cp\u003e\n        当设置为 off（默认值）时，\u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e 在将修改后的数据文件刷盘到文件系统失败时，将引发 PANIC 级错误。这样会导致数据库服务器崩溃。这个参数只能在服务器启动时被设置。\n       \u003c/p\u003e\u003cp\u003e\n        在某些操作系统上，回写失败后，内核页面缓存中的数据状态未知。在某些情况下，它可能已被完全遗忘，因此重试不安全；第二次尝试可能报告为成功，而事实上数据已丢失。在此类情形下，避免数据丢失的唯一方法是在报告任何故障后从 WAL 中恢复，最好是在调查了故障的根本原因并更换了任何有故障的硬件之后。\n       \u003c/p\u003e\u003cp\u003e\n        如果设置为开（on），\u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e 将报告错误，但会继续运行，以便可以在以后的检查点中重试数据刷盘操作。只有在调查清楚操作系统在回写失败时如何处理缓冲数据之后，才应将其设置为开（on）。\n       \u003c/p\u003e","doc":{"anchor":"GUC-DATA-SYNC-RETRY","file":"runtime-config-error-handling.html","lang":"en","sha256":"9819b00085eb96d651c6f6c3d42e9f4f9072fede4729c95234efd6d29dd41d28","slug":"18"},"documented":true,"enumvals":null,"extra_desc":null,"lang":"en","max_val":null,"metadata_version":"18","min_val":null,"name":"data_sync_retry","short_desc":"Whether to continue running after a failure to sync data files.","source":"pg-settings-source-snapshot","translation_provenance":{"inputs":[{"kind":"current-pgdoc-translation","path":"/Users/vonng/pgsty/pgdoc/zh/18/html/runtime-config-error-handling.html","sha256":"a5472f478d8fdcd57a74bc841507dd1849bc56ee7a1dad5b1ce52541b9c69585"}],"kind":"same-version-pgdoc","locale":"zh-Hans","source_revision":"b1b500221dbe5437cfca004d6b04d3f6e422765d","version":"18"},"unit":null,"vartype":"bool","zh_from":"same-version-pgdoc"},"ManualEvidence":{"doc":{"anchor":"GUC-DATA-SYNC-RETRY","file":"runtime-config-error-handling.html","lang":"en","sha256":"9819b00085eb96d651c6f6c3d42e9f4f9072fede4729c95234efd6d29dd41d28","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"data_sync_retry","SourceDatabase":"center","Version":"18","Locale":"en","Title":"data_sync_retry","Summary":"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.","BodyHTML":"\u003cp\u003eWhen 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\u0026#39;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\u0026#39;s treatment of buffered data in case of write-back failure.\u003c/p\u003e","SourceRevision":"wiki-repair-20261023:29a41c41144e2e5602b1dceb5e19170ab7f3420c16793ca813ddc05aff9d0e82","ContentHash":"cbc4aee0f2985d47421fd087e9aac5ff8dd01a7512c3586df8ab9476af58968d","Payload":{"description":"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."}},"RequestedLocale":"en","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20","9.4","9.5","9.6"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}