fsync

Definition PG 18 manual

If this parameter is on, the PostgreSQL server will try to make sure that updates are physically written to disk, by issuing fsync() system calls or various equivalent methods (see wal_sync_method). This ensures that the database cluster can recover to a consistent state after an operating system or hardware crash.

While turning off fsync is often a performance benefit, this can result in unrecoverable data corruption in the event of a power failure or system crash. Thus it is only advisable to turn off fsync if you can easily recreate your entire database from external data.

Examples of safe circumstances for turning off fsync include the initial loading of a new database cluster from a backup file, using a database cluster for processing a batch of data after which the database will be thrown away and recreated, or for a read-only database clone which gets recreated frequently and is not used for failover. High quality hardware alone is not a sufficient justification for turning off fsync.

For reliable recovery when changing fsync off to on, it is necessary to force all modified buffers in the kernel to durable storage. This can be done while the cluster is shutdown or while fsync is on by running initdb --sync-only, running sync, unmounting the file system, or rebooting the server.

In many situations, turning off synchronous_commit for noncritical transactions can provide much of the potential performance benefit of turning off fsync, without the attendant risks of data corruption.

fsync can only be set in the postgresql.conf file or on the server command line. If you turn this parameter off, also consider turning off full_page_writes.

How it works

Forces synchronization of updates to disk. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

When on, PostgreSQL issues durability barriers so WAL and data ordering survive an operating-system or power failure. Turning it off may improve write benchmarks, but a crash can leave corruption that crash recovery cannot repair; re-enabling it does not retroactively synchronize earlier unsafe writes.

Monitor and change fsync together with data_sync_retry, restart_after_crash, recovery_init_sync_method. 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.

Operational considerations

Disabling it on persistent data and assuming UPS or RAID cache alone is sufficient.

Re-enabling it after unsafe operation and assuming earlier writes became durable.

Benchmarking only clean shutdowns instead of power-loss recovery.

Confusing pg_settings base units with human-readable configuration units.

Benchmarking throughput without a crash-recovery and archive-restore test.

Workload guidance

OLAP: Bulk loads still need recoverability. Use explicitly rebuildable UNLOGGED/temporary staging to narrow the durability scope rather than disabling protection cluster-wide.

OLTP: Keep fsync=on for persistent production data. Address storage latency, checkpoints, WAL compression, and batching instead of exchanging crash safety for throughput.

SMALL: Keep it on for persistent small instances too. Only a clearly isolated, disposable cluster may make an exception after explicitly accepting rebuild risk.