wal_writer_delay

Definition PG 18 manual

Specifies how often the WAL writer flushes WAL, in time terms. After flushing WAL the writer sleeps for the length of time given by wal_writer_delay, unless woken up sooner by an asynchronously committing transaction. If the last flush happened less than wal_writer_delay ago and less than wal_writer_flush_after worth of WAL has been produced since, then WAL is only written to the operating system, not flushed to disk. If this value is specified without units, it is taken as milliseconds. The default value is 200 milliseconds (200ms). Note that on some systems, the effective resolution of sleep delays is 10 milliseconds; setting wal_writer_delay to a value that is not a multiple of 10 might have the same results as setting it to the next higher multiple of 10. This parameter can only be set in the postgresql.conf file or on the server command line.

How it works

Time between WAL flushes performed in the WAL writer. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

The WAL writer sleeps for this interval between activity checks, but may wake earlier under pressure. Shorter delays can move writes out of foreground commits at the price of wakeups; durability timing still depends on wal_writer_flush_after and commit behavior.

Monitor and change wal_writer_delay together with fsync, full_page_writes, wal_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

Treating the interval as a strict commit-flush deadline; the writer can wake earlier and foreground commits can flush independently.

Setting it very low and paying excessive wakeup and small-write overhead.

Setting it very high and moving more WAL writes into foreground backends.

Ignoring wal_writer_flush_after when interpreting write versus durable-flush timing.

Using asynchronous commit without budgeting its possible loss window.

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_writer_delay 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.