When set to fsync, which is the default, PostgreSQL will recursively open and synchronize all files in the data directory before crash recovery begins.
At a glance
| Property | Value |
|---|---|
| Parameter | recovery_init_sync_method |
| Category | Error Handling |
| Default | (see documentation) |
| Value type | enum |
| Change scope | Per-session (SET) |
| Available in | PostgreSQL 14, 15, 16, 17, 18, 19 (added in 14) |
What it does
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.
(Description quoted from the official PostgreSQL documentation.)
How to apply a change
Can be set per session with SET, per role/database with ALTER ROLE/DATABASE ... SET, or globally in postgresql.conf.
Inspect the current value and source with SHOW recovery_init_sync_method; or SELECT name, setting, unit, context, source FROM pg_settings WHERE name = 'recovery_init_sync_method';.
Tuning guidance
This parameter is rarely a performance lever. Leave it at the default unless you have a specific, documented reason to change it, change it on one session or one role/database first, and confirm the effect with pg_settings and your own measurements before rolling it out cluster-wide.