wal_writer_flush_after

Definition PG 18 manual

Specifies how often the WAL writer flushes WAL, in volume terms. 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 wal_writer_flush_after is set to 0 then WAL data is always flushed immediately. If this value is specified without units, it is taken as WAL blocks, that is XLOG_BLCKSZ bytes, typically 8kB. The default is 1MB. This parameter can only be set in the postgresql.conf file or on the server command line.

How it works

Amount of WAL written out by WAL writer that triggers a flush. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

After this volume since its last flush, the WAL writer forces written WAL to durable storage; otherwise it may only write to the OS. Zero flushes immediately, while larger values trade background smoothing against a bigger dirty-WAL window for asynchronous commits.

Monitor and change wal_writer_flush_after together with wal_buffers, wal_writer_delay, 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

Reading an unqualified value as bytes rather than WAL blocks.

Forgetting that zero requests an immediate flush from the WAL writer.

Choosing a large batch without considering asynchronous-commit loss exposure and dirty WAL.

Treating the setting as a replacement for synchronous commit flushes.

Tuning it without wal_writer_delay and storage flush latency.

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