Parameter · Write-Ahead Log / Settings
wal_sync_method
Selects the method used for forcing WAL updates to disk.
- Default:
fdatasync - Type: enum
- Values: fsync · fdatasync · open_sync · open_datasync
- Applies: Reload
In plain words
At commit, PostgreSQL must make sure the WAL reached stable storage. There are several ways to ask the operating system for that, and wal_sync_method picks one. The default is the safe, well-tested choice for the platform (fdatasync on Linux).
Change it only after measuring with pg_test_fsync, and only if your disks honour flushes.
For DBAs and operators
- fdatasync: write the WAL, then
fdatasync()the file: data plus only the metadata needed to read it back. Default on Linux and FreeBSD. - fsync: same, but also flushes all file metadata (timestamps). Slightly more work.
- open_datasync / open_sync: the WAL file is opened with
O_DSYNC/O_SYNC, so everywrite()is itself synchronous. - fsync_writethrough (only on macOS in PostgreSQL 18, so not in this Linux server's list): forces through the drive's write cache.
The OS call is only as good as the storage under it: a drive or controller with a volatile write cache that ignores flush requests can lose "committed" data on power loss whatever method you choose. Use battery/flash-backed caches or enterprise SSDs with power-loss protection.
Measuring
pg_test_fsync -f /path/on/the/wal/volume/testfileIt reports operations per second for each method. Performance alone does not prove power-loss durability, so storage-cache behavior and power-loss protection should be validated separately. In PostgreSQL 18 the time spent in WAL syncs is reported in pg_stat_io (object = 'wal', fsyncs, fsync_time with track_wal_io_timing); the older pg_stat_wal.wal_sync columns moved there.
How to change it
Change in postgresql.conf or ALTER SYSTEM, then run SELECT pg_reload_conf().