wal_writer_delay

wal_writer_delay — Time between WAL flushes performed in the WAL writer. Observed in PG9.0–19 Beta 3; its last measured boot default is 200 ms in PG19 Beta 3, with sighup context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Time between WAL flushes performed in the WAL writer.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valuesighup: Takes effect after configuration reload
Unit , Valuems: Raw unit
Range , Value1 – 10000: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueWrite-Ahead Log / Settings: Upstream classification
Latest boot value , Value200: 200 ms

Lifecycle

Fact	Value
First observed	PG9.0 (research boundary)
Present in	PG9.0–19 Beta 3
Removed in	No
Introduction commit	Not asserted: predates the PG9.0 research boundary
Commit date	—
Discussion	—

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG9.0–19 Beta 3	`200`	`ms`	200 ms

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.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
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.
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.
Small nodes	Start from safe defaults or the measured Pigsty value and set explicit alerts for limited disk capacity. Do not disable durability or break the recovery chain merely to save modest I/O.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	`20ms`	different	`20ms`
OLAP	`20ms`	different	`20ms`
CRIT	`10ms`	different	`10ms`
TINY	`20ms`	different	`20ms`

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–19 Beta 3 = 20ms (dcs); OLAP: PG9.0–19 Beta 3 = 20ms (dcs); CRIT: PG9.0–19 Beta 3 = 10ms (dcs); TINY: PG9.0–19 Beta 3 = 20ms (dcs). Advice, pending human review — Editorial interpretation, pending human maintainer review: the override appears intended to move WAL out of foreground backends more frequently, with an even shorter CRIT cadence; confirm it against the current Pigsty templates, hardware fixture, and operational guarantees before publication.

Common pitfalls

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.

fsync · full_page_writes · wal_sync_method · synchronous_commit · wal_buffers · commit_delay