{"Entry":{"collection":"guc","key":"recovery_init_sync_method","name":"recovery_init_sync_method","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Error Handling","category_zh":"","changed_in":[],"changes":[{"documentation_changed":false,"fields":{},"from":"13","status":"added","to":"14"},{"documentation_changed":true,"fields":{},"from":"16","status":"changed","to":"17"}],"content_hash":"d9491414a7cb66b50aa85e04065dfaa473cd3897994538a083256bcdbdef74d0","context":"","default_changed_in":[],"default_history":[{"from":"14","to":"19","value":"fsync"}],"derived_content_hash":"41ebd12fa9862da43e76cb561b2633d5c0eb9c1fc36195ed07f65a79e4a3367e","editorial":{"advice":{"olap":"Test separately under long queries, batch jobs, and peak concurrency rather than copying OLTP assumptions to analytical nodes.","oltp":"Change recovery_init_sync_method 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":["Sets the method for synchronizing the data directory before crash recovery. A configuration reload applies a new value; existing work already in flight is not retroactively changed.","Before crash recovery, PostgreSQL synchronizes the data directory so replay is not built on unflushed copied files. fsync walks files portably; where supported, syncfs can synchronize the containing filesystem more quickly but has a broader scope.","Monitor and change recovery_init_sync_method together with data_sync_retry, restart_after_crash, fsync. 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":["Confusing the boot default of recovery_init_sync_method with its current effective value.","Ignoring its sighup context when deciding when it takes effect.","Changing several interacting settings at once and losing causal evidence.","Rolling out globally without testing the real failure or workload boundary."],"references":[{"title":"PostgreSQL 19 Beta 4: recovery_init_sync_method","url":"https://www.postgresql.org/docs/19/runtime-config-error-handling.html#GUC-RECOVERY-INIT-SYNC-METHOD"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["data_sync_retry","restart_after_crash","fsync","full_page_writes","exit_on_error"],"summary":"recovery_init_sync_method sets the method for synchronizing the data directory before crash recovery. It is a sighup setting present in PG14–18; the latest recorded boot default is fsync."},"enumvals":[],"first_version":"14","group":"Error Handling","group_slug":"error-handling","imported_at":"2026-09-27T17:57:31.862972+08:00","intro_commit":{"authored_at":"2021-03-20T11:46:32+13:00","discussion":["https://postgr.es/m/11bc2bb7-ecb5-3ad0-b39f-df632734cd81%40discourse.org","https://postgr.es/m/CAEET0ZHGnbXmi8yF3ywsDZvb3m9CbdsGZgfTXscQ6agcbzcZAw%40mail.gmail.com"],"hash":"61752afb26404dfc99a535c7a53f7f04dc110263","subject":"Provide recovery_init_sync_method=syncfs.","url":"https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=61752afb26404dfc99a535c7a53f7f04dc110263"},"key":"recovery_init_sync_method","last_version":"20","max_val":"","min_val":"","name":"recovery_init_sync_method","position":322,"present_in":["14","15","16","17","18","19","20"],"repair_provenance":{"original_source_revision":"english-manuals:e3f8b9d9f90beb759843e2655c35c2be51982d5832abf7d7a97377ae793b734e","receipt_sha256":"7659bb1fd2a04e46fdcde9f2e7ae4b3abd314f6d269f90a1d05e54ca4fa452ad","repair":"wiki-repair-20261023"},"short_desc":"When set to fsync, which is the default, PostgreSQL will recursively open and synchronize all files in the data directory before crash recovery begins.","short_desc_zh":"","source_rev":"wiki-repair-20261023:7ff9991d60ef1a1e2e532d66aa15de09ee040453079e9ff438c66efdb59fb9d3","unit":"","vartype":"enum"}},"Definition":{"Collection":"guc","Key":"recovery_init_sync_method","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"recovery_init_sync_method","SourceRevision":"wiki-repair-20261023:7ff9991d60ef1a1e2e532d66aa15de09ee040453079e9ff438c66efdb59fb9d3","Facts":{"boot_val":"fsync","category":"Error Handling","context":"sighup","description":"When set to fsync, which is the default, PostgreSQL will recursively open and synchronize all files in the data directory before crash recovery begins. The search for files will follow symbolic links for the WAL directory and each configured tablespace (but not any other symbolic links). This is intended to make sure that all WAL and data files are durably stored on disk before replaying changes. This applies whenever starting a database cluster that did not shut down cleanly, including copies created with pg_basebackup. On Linux, syncfs may be used instead, to ask the operating system to synchronize the file systems that contain the data directory, the WAL files and each tablespace (but not any other file systems that may be reachable through symbolic links). This may be a lot faster than the fsync setting, because it doesn't need to open each file one by one. On the other hand, it may be slower if a file system is shared by other applications that modify a lot of files, since those files will also be written to disk. Furthermore, on versions of Linux before 5.8, I/O errors encountered while writing data to disk may not be reported to PostgreSQL, and relevant error messages may appear only in kernel logs. This parameter can only be set in the postgresql.conf file or on the server command line.","description_zh":"当设置为 fsync，也就是默认值，PostgreSQL 将在崩溃恢复开始之前递归地打开并同步数据目录中的所有文件。对文件的搜索将遵循 WAL 目录和每个配置表空间的符号链接（而不是任何其他符号链接）。这是为了确保在重放更改之前，所有 WAL 和数据文件都持久地存储在磁盘上。这适用于每次启动未正常关闭的数据库集簇时，包括由 pg_basebackup 创建的副本。 在 Linux 上，可以用 syncfs 代替，请求操作系统来同步数据目录、WAL 文件和各个表空间所在的文件系统（但不是通过符号链接可访问到的任何其他文件系统）。这可能比 fsync 设置快得多，因为它不需要逐个打开每个文件。另一方面，如果一个文件系统是被其他需要修改大量文件的应用程序共享的，它可能会慢一些，因为这些文件也将写入磁盘。此外，在 5.8 之前的 Linux 版本中，向磁盘写入数据时遇到的 I/O 错误可能不会报告给 PostgreSQL，相关的错误消息可能只出现在内核日志中。 这个参数只能在 postgresql.conf 文件中或者服务器命令行中设置。","description_zh_html":"\u003cp\u003e\n        当设置为 \u003ccode class=\"literal\"\u003efsync\u003c/code\u003e，也就是默认值，\u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e 将在崩溃恢复开始之前递归地打开并同步数据目录中的所有文件。对文件的搜索将遵循 WAL 目录和每个配置表空间的符号链接（而不是任何其他符号链接）。这是为了确保在重放更改之前，所有 WAL 和数据文件都持久地存储在磁盘上。这适用于每次启动未正常关闭的数据库集簇时，包括由 \u003cspan class=\"application\"\u003epg_basebackup\u003c/span\u003e 创建的副本。\n       \u003c/p\u003e\u003cp\u003e\n        在 Linux 上，可以用 \u003ccode class=\"literal\"\u003esyncfs\u003c/code\u003e 代替，请求操作系统来同步数据目录、WAL 文件和各个表空间所在的文件系统（但不是通过符号链接可访问到的任何其他文件系统）。这可能比 \u003ccode class=\"literal\"\u003efsync\u003c/code\u003e 设置快得多，因为它不需要逐个打开每个文件。另一方面，如果一个文件系统是被其他需要修改大量文件的应用程序共享的，它可能会慢一些，因为这些文件也将写入磁盘。此外，在 5.8 之前的 Linux 版本中，向磁盘写入数据时遇到的 I/O 错误可能不会报告给 \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e，相关的错误消息可能只出现在内核日志中。\n       \u003c/p\u003e\u003cp\u003e\n        这个参数只能在 \u003ccode class=\"filename\"\u003epostgresql.conf\u003c/code\u003e 文件中或者服务器命令行中设置。\n       \u003c/p\u003e","doc":{"anchor":"GUC-RECOVERY-INIT-SYNC-METHOD","file":"runtime-config-error-handling.html","lang":"en","sha256":"9819b00085eb96d651c6f6c3d42e9f4f9072fede4729c95234efd6d29dd41d28","slug":"18"},"documented":true,"enumvals":["fsync","syncfs"],"extra_desc":null,"lang":"en","max_val":null,"metadata_version":"18","min_val":null,"name":"recovery_init_sync_method","short_desc":"Sets the method for synchronizing the data directory before crash recovery.","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":"enum","zh_from":"same-version-pgdoc"},"ManualEvidence":{"doc":{"anchor":"GUC-RECOVERY-INIT-SYNC-METHOD","file":"runtime-config-error-handling.html","lang":"en","sha256":"9819b00085eb96d651c6f6c3d42e9f4f9072fede4729c95234efd6d29dd41d28","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"recovery_init_sync_method","SourceDatabase":"center","Version":"18","Locale":"en","Title":"recovery_init_sync_method","Summary":"When set to fsync, which is the default, PostgreSQL will recursively open and synchronize all files in the data directory before crash recovery begins. The search for files will follow symbolic links for the WAL directory and each configured tablespace (but not any other symbolic links). This is intended to make sure that all WAL and data files are durably stored on disk before replaying changes. This applies whenever starting a database cluster that did not shut down cleanly, including copies created with pg_basebackup. On Linux, syncfs may be used instead, to ask the operating system to synchronize the file systems that contain the data directory, the WAL files and each tablespace (but not any other file systems that may be reachable through symbolic links). This may be a lot faster than the fsync setting, because it doesn't need to open each file one by one. On the other hand, it may be slower if a file system is shared by other applications that modify a lot of files, since those files will also be written to disk. Furthermore, on versions of Linux before 5.8, I/O errors encountered while writing data to disk may not be reported to PostgreSQL, and relevant error messages may appear only in kernel logs. This parameter can only be set in the postgresql.conf file or on the server command line.","BodyHTML":"\u003cp\u003eWhen set to fsync, which is the default, PostgreSQL will recursively open and synchronize all files in the data directory before crash recovery begins. The search for files will follow symbolic links for the WAL directory and each configured tablespace (but not any other symbolic links). This is intended to make sure that all WAL and data files are durably stored on disk before replaying changes. This applies whenever starting a database cluster that did not shut down cleanly, including copies created with pg_basebackup. On Linux, syncfs may be used instead, to ask the operating system to synchronize the file systems that contain the data directory, the WAL files and each tablespace (but not any other file systems that may be reachable through symbolic links). This may be a lot faster than the fsync setting, because it doesn\u0026#39;t need to open each file one by one. On the other hand, it may be slower if a file system is shared by other applications that modify a lot of files, since those files will also be written to disk. Furthermore, on versions of Linux before 5.8, I/O errors encountered while writing data to disk may not be reported to PostgreSQL, and relevant error messages may appear only in kernel logs. This parameter can only be set in the postgresql.conf file or on the server command line.\u003c/p\u003e","SourceRevision":"wiki-repair-20261023:7ff9991d60ef1a1e2e532d66aa15de09ee040453079e9ff438c66efdb59fb9d3","ContentHash":"3b35aab53ae47e583cc60c41fa0b22c329f2489b5d6e91c86eb6c9c590c3e7dd","Payload":{"description":"When set to fsync, which is the default, PostgreSQL will recursively open and synchronize all files in the data directory before crash recovery begins. The search for files will follow symbolic links for the WAL directory and each configured tablespace (but not any other symbolic links). This is intended to make sure that all WAL and data files are durably stored on disk before replaying changes. This applies whenever starting a database cluster that did not shut down cleanly, including copies created with pg_basebackup. On Linux, syncfs may be used instead, to ask the operating system to synchronize the file systems that contain the data directory, the WAL files and each tablespace (but not any other file systems that may be reachable through symbolic links). This may be a lot faster than the fsync setting, because it doesn't need to open each file one by one. On the other hand, it may be slower if a file system is shared by other applications that modify a lot of files, since those files will also be written to disk. Furthermore, on versions of Linux before 5.8, I/O errors encountered while writing data to disk may not be reported to PostgreSQL, and relevant error messages may appear only in kernel logs. This parameter can only be set in the postgresql.conf file or on the server command line."}},"RequestedLocale":"en","Fallback":false,"Versions":["14","15","16","17","18","19","20"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}