Parameter · Write-Ahead Log / Settings

fsync

Forces synchronization of updates to disk. 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.

Default: on
Type: bool
Applies: Reload

In plain words

When PostgreSQL says "committed", it has asked the operating system to put the WAL physically on disk with fsync(). With fsync = off it skips that and trusts the OS cache. It is faster, but after a power loss or OS crash the data files and WAL can be inconsistent with each other, and the damage can be silent and unrecoverable.

Only use off for throw-away data you can recreate from scratch, such as a one-time initial load you would redo after a crash.

For DBAs and operators

fsync affects every place PostgreSQL forces data to stable storage: WAL flushes at commit, checkpoint syncs of data files, file creation and renames. With it off, a PostgreSQL process crash is still safe (the OS cache survives), but an OS crash, kernel panic, power loss or hypervisor failure can leave pages half-written, WAL missing records that data pages already reflect, or pg_control pointing to a checkpoint that never fully reached disk. Recovery may then "succeed" and leave corrupt indexes, duplicate keys, or lost rows that surface weeks later.

If fsync was ever off when an OS-level crash happened, treat the cluster as suspect: restore from backup or dump and reload. Turning it back on later does not repair anything.

Safer alternatives

synchronous_commit = off gives most of the speed for small commits, and a crash only loses the last few hundred milliseconds of commits: no corruption.
For bulk loads, wal_level = minimal with COPY into a new table, or unlogged tables.

Related facts

wal_sync_method is irrelevant when fsync is off, and commit_delay is skipped.
Since the 2018 "fsyncgate" fix, PostgreSQL PANICs on an fsync failure rather than retrying (data_sync_retry = off), because the kernel may have dropped the dirty pages.
Check with SHOW fsync; and look in postgresql.auto.conf: support tickets sometimes find it disabled "temporarily" months ago.

How to change it

Change in postgresql.conf or ALTER SYSTEM, then run SELECT pg_reload_conf().

See it in context

Write-ahead log (WAL) Crash recovery WAL writer

Related parameters

synchronous_commit wal_sync_method full_page_writes commit_delay

All Write-Ahead Log parameters