↑↓ select ↵ open ⌫ change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

CONFIGURATION / WRITE-AHEAD LOG

wal_sync_method

Read PG 18 manual ↗

Method used for forcing WAL updates out to disk.

Type
enum
Context
sighup
Measured default
fdatasync
Unit
—
Metadata snapshot
18
Allowed values
fsync, fdatasync, open_sync, open_datasync

Definition PG 18 manual

Method used for forcing WAL updates out to disk. If fsync is off then this setting is irrelevant, since WAL file updates will not be forced out at all. Possible values are:

  • open_datasync (write WAL files with open() option O_DSYNC)

  • fdatasync (call fdatasync() at each commit)

  • fsync (call fsync() at each commit)

  • fsync_writethrough (call fsync() at each commit, forcing write-through of any disk write cache)

  • open_sync (write WAL files with open() option O_SYNC)

Not all of these choices are available on all platforms. The default is the first method in the above list that is supported by the platform, except that fdatasync is the default on Linux and FreeBSD. The default is not necessarily ideal; it might be necessary to change this setting or other aspects of your system configuration in order to create a crash-safe configuration or achieve optimal performance. These aspects are discussed in Section 28.1. This parameter can only be set in the postgresql.conf file or on the server command line.

Measured default history
Version intervalDefault
9.0 – 19fdatasync
Analysis & operational context

Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗

How it works

Selects the method used for forcing WAL updates to disk. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

This chooses the operating-system primitive used to force WAL to durable storage, such as fdatasync, fsync, or open-sync variants. Availability and performance are platform/filesystem specific; all supported choices preserve the durability contract when the stack is honest.

Monitor and change wal_sync_method together with fsync, full_page_writes, synchronous_commit. 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

Selecting a method that the operating system or filesystem does not support.

Benchmarking on a different kernel, mount option, or storage cache than production.

Confusing write throughput with durable-sync latency.

Changing the method without a crash/power-loss durability test.

Assuming the fastest method on data files is also the best method for WAL.

Workload guidance

OLAP: Provision WAL, archive bandwidth, and recovery I/O for bulk-load peaks. Coordinate load pacing and checkpoints when reducing spikes; never break the recovery chain for throughput.

OLTP: Establish durability and recovery objectives first, then tune wal_sync_method from WAL rate, flush latency, checkpoints, and peak pg_wal usage. Validate every change with crash/recovery and archive monitoring.

SMALL: Start from safe defaults and set explicit alerts for limited disk capacity. Do not disable durability or break the recovery chain merely to save modest I/O.

Version history 5
  1. PG 16 → 17changed
  2. PG 15 → 16changed
  3. PG 13 → 14changed
  4. PG 11 → 12changed
  5. PG 9.5 → 9.6changed

Related entries

commit_delay →fsync →full_page_writes →synchronous_commit →wal_buffers →wal_writer_delay →

Further reading

Definition snapshot: english-manuals:03adcd39c1aec1d4b38dd995710… · English manual source