Parameter · Error Handling
recovery_init_sync_method
Sets the method for synchronizing the data directory before crash recovery.
- Default:
fsync - Type: enum
- Values: fsync · syncfs
- Applies: Reload
In plain words
Before replaying WAL after a crash, PostgreSQL makes sure every file in the data directory is safely on disk, because some writes may still have been sitting in the OS cache. The default fsync opens and flushes each file one by one, which can take many minutes with hundreds of thousands of files. syncfs (Linux) flushes whole file systems in one call instead.
For DBAs and operators
fsync: walks $PGDATA and all tablespaces, opening and fsyncing every file (plus directories). Cost grows with the number of files, even if nothing is dirty; on clusters with many tables/partitions this can delay startup significantly, especially on network storage.
syncfs (Linux only, PostgreSQL 14+): one syncfs() per file system that contains the data directory, pg_wal or tablespaces. Usually much faster, but it also flushes unrelated files on those file systems, and on Linux kernels before 5.8 write-back errors may not be reported by syncfs.
Progress is logged every log_startup_progress_interval:
LOG: syncing data directory (fsync), elapsed time: 52.04 s, current path: ./base/16384/1259_vm
Only used when starting a cluster that was not shut down cleanly (after a crash, and also for copies made with pg_basebackup), not after a clean shutdown. If crash restarts take minutes before WAL replay even starts, this sync is the usual suspect; try syncfs.
How to change it
Change in postgresql.conf or ALTER SYSTEM, then run SELECT pg_reload_conf().
See it in context
Related parameters
restart_after_crash data_sync_retry log_startup_progress_interval fsync