{"Entry":{"collection":"guc","key":"fsync","name":"fsync","aliases":[],"metadata":{"baseline":true,"boot_human":"Not specified","boot_val":null,"category":"Write-Ahead Log / Settings","category_zh":"","changed_in":["12"],"changes":[{"documentation_changed":true,"fields":{},"from":"7.4","status":"changed","to":"8.0"},{"documentation_changed":true,"fields":{},"from":"8.0","status":"changed","to":"8.1"},{"documentation_changed":true,"fields":{},"from":"8.1","status":"changed","to":"8.2"},{"documentation_changed":true,"fields":{},"from":"8.2","status":"changed","to":"8.3"},{"documentation_changed":true,"fields":{},"from":"8.4","status":"changed","to":"9.0"},{"documentation_changed":true,"fields":{},"from":"9.2","status":"changed","to":"9.3"},{"documentation_changed":false,"fields":{"extra_desc":{"from":"The server will use the fsync() system call in several places to make sure that updates are physically written to disk. This insures that a database cluster will recover to a consistent state after an operating system or hardware crash.","to":"The server will use the fsync() system call in several places to make sure that updates are physically written to disk. This ensures that a database cluster will recover to a consistent state after an operating system or hardware crash."}},"from":"11","status":"changed","to":"12"}],"content_hash":"f33d1c24f57716c8ed493cc7f0f1ff964072ff30c2296e15b42f5244dffe422f","context":"","default_changed_in":[],"default_history":[{"from":"9.0","to":"19","value":"on"}],"editorial":{"advice":{"olap":"Bulk loads still need recoverability. Use explicitly rebuildable UNLOGGED/temporary staging to narrow the durability scope rather than disabling protection cluster-wide.","oltp":"Keep fsync=on for persistent production data. Address storage latency, checkpoints, WAL compression, and batching instead of exchanging crash safety for throughput.","small":"Keep it on for persistent small instances too. Only a clearly isolated, disposable cluster may make an exception after explicitly accepting rebuild risk."},"mechanism":["Forces synchronization of updates to disk. A configuration reload applies a new value; existing work already in flight is not retroactively changed.","When on, PostgreSQL issues durability barriers so WAL and data ordering survive an operating-system or power failure. Turning it off may improve write benchmarks, but a crash can leave corruption that crash recovery cannot repair; re-enabling it does not retroactively synchronize earlier unsafe writes.","Monitor and change fsync together with data_sync_retry, restart_after_crash, recovery_init_sync_method. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value."],"pitfalls":["Disabling it on persistent data and assuming UPS or RAID cache alone is sufficient.","Re-enabling it after unsafe operation and assuming earlier writes became durable.","Benchmarking only clean shutdowns instead of power-loss recovery.","Confusing pg_settings base units with human-readable configuration units.","Benchmarking throughput without a crash-recovery and archive-restore test."],"references":[{"title":"PostgreSQL 19 Beta 4: fsync","url":"https://www.postgresql.org/docs/19/runtime-config-wal.html#GUC-FSYNC"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["data_sync_retry","restart_after_crash","recovery_init_sync_method","full_page_writes","wal_sync_method","synchronous_commit"],"summary":"fsync — Forces synchronization of updates to disk. Observed in PG9.0–19 Beta 4; its last measured boot default is on in PG19 Beta 4, with sighup context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA."},"enumvals":[],"first_version":"7.4","group":"Write-Ahead Log","group_slug":"wal","imported_at":"2026-09-27T17:57:31.292598+08:00","intro_commit":{},"key":"fsync","last_version":"20","max_val":"","min_val":"","name":"fsync","position":151,"present_in":["7.4","8.0","8.1","8.2","8.3","8.4","9.0","9.1","9.2","9.3","9.4","9.5","9.6","10","11","12","13","14","15","16","17","18","19","20"],"short_desc":"If this parameter is on, the PostgreSQL server will try to make sure that updates are physically written to disk, by issuing fsync() system calls or various equivalent methods (see wal_sync_method).","short_desc_zh":"","source_rev":"english-manuals:b356cc65656f00502b0a8421f2c8c1f51a387f3a31b19ec4eebee2b5b2bc95ed","unit":"","vartype":"bool"}},"Definition":{"Collection":"guc","Key":"fsync","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"fsync","SourceRevision":"english-manuals:b356cc65656f00502b0a8421f2c8c1f51a387f3a31b19ec4eebee2b5b2bc95ed","Facts":{"boot_val":"on","category":"Write-Ahead Log / Settings","context":"sighup","description":"If this parameter is on, the PostgreSQL server will try to make sure that updates are physically written to disk, by issuing fsync() system calls or various equivalent methods (see wal_sync_method). This ensures that the database cluster can recover to a consistent state after an operating system or hardware crash. While turning off fsync is often a performance benefit, this can result in unrecoverable data corruption in the event of a power failure or system crash. Thus it is only advisable to turn off fsync if you can easily recreate your entire database from external data. Examples of safe circumstances for turning off fsync include the initial loading of a new database cluster from a backup file, using a database cluster for processing a batch of data after which the database will be thrown away and recreated, or for a read-only database clone which gets recreated frequently and is not used for failover. High quality hardware alone is not a sufficient justification for turning off fsync. For reliable recovery when changing fsync off to on, it is necessary to force all modified buffers in the kernel to durable storage. This can be done while the cluster is shutdown or while fsync is on by running initdb --sync-only, running sync, unmounting the file system, or rebooting the server. In many situations, turning off synchronous_commit for noncritical transactions can provide much of the potential performance benefit of turning off fsync, without the attendant risks of data corruption. fsync can only be set in the postgresql.conf file or on the server command line. If you turn this parameter off, also consider turning off full_page_writes.","doc":{"anchor":"GUC-FSYNC","file":"runtime-config-wal.html","lang":"en","sha256":"d2646404a06e8f7ac655204b4f28c049ae8f3fd4f2272db080fcefa2c4af0763","slug":"18"},"documented":true,"enumvals":null,"extra_desc":"The server will use the fsync() system call in several places to make sure that updates are physically written to disk. This ensures that a database cluster will recover to a consistent state after an operating system or hardware crash.","lang":"en","max_val":null,"metadata_version":"18","min_val":null,"name":"fsync","short_desc":"Forces synchronization of updates to disk.","source":"pg-settings-source-snapshot","unit":null,"vartype":"bool"},"ManualEvidence":{"doc":{"anchor":"GUC-FSYNC","file":"runtime-config-wal.html","lang":"en","sha256":"d2646404a06e8f7ac655204b4f28c049ae8f3fd4f2272db080fcefa2c4af0763","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"fsync","SourceDatabase":"pgweb","Version":"18","Locale":"zh-Hans","Title":"fsync","Summary":"","BodyHTML":"\u003cp\u003e如果打开这个参数，\u003cspan\u003ePostgreSQL\u003c/span\u003e服务器将尝试确保更新被物理地写入到磁盘，做法是发出\u003ccode\u003efsync()\u003c/code\u003e系统调用或者使用多种等价的方法（见\u003ca href=\"/docs/18/runtime-config-wal.html#GUC-WAL-SYNC-METHOD\" rel=\"nofollow\"\u003ewal_sync_method\u003c/a\u003e）。这保证了数据库集簇在一次操作系统或者硬件崩溃后能恢复到一个一致的状态。\u003c/p\u003e\u003cp\u003e虽然关闭\u003ccode\u003efsync\u003c/code\u003e常常可以得到性能上的收益，但当发生断电或系统崩溃时可能造成不可恢复的数据损坏。因此，只有在能很容易地从外部数据中重建整个数据库时才建议关闭\u003ccode\u003efsync\u003c/code\u003e。\u003c/p\u003e\u003cp\u003e可以安全关闭\u003ccode\u003efsync\u003c/code\u003e的情形包括：从备份文件初始装载一个新数据库集簇；用数据库集簇处理一批数据，处理后就丢弃并重建该数据库；或者使用经常重建且不用于故障切换的只读数据库克隆。仅有高质量硬件不足以成为关闭\u003ccode\u003efsync\u003c/code\u003e的理由。\u003c/p\u003e\u003cp\u003e为确保将\u003ccode\u003efsync\u003c/code\u003e从关闭改为打开后能够可靠恢复，必须将内核中所有已修改的缓冲区强制写入持久存储。可以在集簇已关闭或\u003ccode\u003efsync\u003c/code\u003e已开启时，通过运行\u003ccode\u003einitdb --sync-only\u003c/code\u003e、运行\u003ccode\u003esync\u003c/code\u003e、卸载文件系统或重启服务器来完成。\u003c/p\u003e\u003cp\u003e在很多情况下，为非关键事务关闭\u003ca href=\"/docs/18/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT\" rel=\"nofollow\"\u003esynchronous_commit\u003c/a\u003e，可以获得关闭\u003ccode\u003efsync\u003c/code\u003e所带来的大部分潜在性能收益，同时避免伴随的数据损坏风险。\u003c/p\u003e\u003cp\u003e\u003ccode\u003efsync\u003c/code\u003e只能在\u003ccode\u003epostgresql.conf\u003c/code\u003e文件中或在服务器命令行上设置。如果你关闭这个参数，请也考虑关闭\u003ca href=\"/docs/18/runtime-config-wal.html#GUC-FULL-PAGE-WRITES\" rel=\"nofollow\"\u003efull_page_writes\u003c/a\u003e。\u003c/p\u003e","SourceRevision":"2026-09-11@29c86d9","ContentHash":"01106fc9cc7dd54a88ed27d0d443007e73c04b153438ae33b77e032016541227","Payload":{"carried_from":"","carry_reason":"","doc_html":"\u003cp\u003e如果打开这个参数，\u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e服务器将尝试确保更新被物理地写入到磁盘，做法是发出\u003ccode class=\"function\"\u003efsync()\u003c/code\u003e系统调用或者使用多种等价的方法（见\u003ca href=\"/docs/18/runtime-config-wal.html#GUC-WAL-SYNC-METHOD\"\u003ewal_sync_method\u003c/a\u003e）。这保证了数据库集簇在一次操作系统或者硬件崩溃后能恢复到一个一致的状态。\u003c/p\u003e\u003cp\u003e虽然关闭\u003ccode class=\"varname\"\u003efsync\u003c/code\u003e常常可以得到性能上的收益，但当发生断电或系统崩溃时可能造成不可恢复的数据损坏。因此，只有在能很容易地从外部数据中重建整个数据库时才建议关闭\u003ccode class=\"varname\"\u003efsync\u003c/code\u003e。\u003c/p\u003e\u003cp\u003e可以安全关闭\u003ccode class=\"varname\"\u003efsync\u003c/code\u003e的情形包括：从备份文件初始装载一个新数据库集簇；用数据库集簇处理一批数据，处理后就丢弃并重建该数据库；或者使用经常重建且不用于故障切换的只读数据库克隆。仅有高质量硬件不足以成为关闭\u003ccode class=\"varname\"\u003efsync\u003c/code\u003e的理由。\u003c/p\u003e\u003cp\u003e为确保将\u003ccode class=\"varname\"\u003efsync\u003c/code\u003e从关闭改为打开后能够可靠恢复，必须将内核中所有已修改的缓冲区强制写入持久存储。可以在集簇已关闭或\u003ccode class=\"varname\"\u003efsync\u003c/code\u003e已开启时，通过运行\u003ccode class=\"command\"\u003einitdb --sync-only\u003c/code\u003e、运行\u003ccode class=\"command\"\u003esync\u003c/code\u003e、卸载文件系统或重启服务器来完成。\u003c/p\u003e\u003cp\u003e在很多情况下，为非关键事务关闭\u003ca href=\"/docs/18/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT\"\u003esynchronous_commit\u003c/a\u003e，可以获得关闭\u003ccode class=\"varname\"\u003efsync\u003c/code\u003e所带来的大部分潜在性能收益，同时避免伴随的数据损坏风险。\u003c/p\u003e\u003cp\u003e\u003ccode class=\"varname\"\u003efsync\u003c/code\u003e只能在\u003ccode class=\"filename\"\u003epostgresql.conf\u003c/code\u003e文件中或在服务器命令行上设置。如果你关闭这个参数，请也考虑关闭\u003ca href=\"/docs/18/runtime-config-wal.html#GUC-FULL-PAGE-WRITES\"\u003efull_page_writes\u003c/a\u003e。\u003c/p\u003e","doc_same_as":""}},"RequestedLocale":"zh-Hans","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20","7.4","8.0","8.1","8.2","8.3","8.4","9.0","9.1","9.2","9.3","9.4","9.5","9.6"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}