# 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 {#identity}

| Field | Value | Meaning |
| --- | --- | --- |
| Type | `integer` | Upstream pg_settings type |
| Context | `sighup` | Takes effect after configuration reload |
| Unit | `ms` | Raw unit |
| Range | `1` – `10000` | Raw limits in the last observed version |
| Enum values | — | — for non-enum types |
| Category | Write-Ahead Log / Settings | Upstream classification |
| Latest boot value | `200` | 200 ms |
{.fields meta="-"}

## Lifecycle {#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 {#default-history}

| Versions | Raw `boot_val` | Unit | Human value |
| --- | --- | --- | --- |
| PG9.0–19 Beta 3 | `200` | `ms` | 200 ms |
{.full-width caption="Measured PG9.0–19 Beta 3 boot defaults"}

## How it works {#mechanism}

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 {#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. |
{.full-width}

## Pigsty {#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` |
{.full-width}

> [!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 {#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.

## Related parameters {#related-parameters}

[`fsync`](/parameters/fsync/) · [`full_page_writes`](/parameters/full-page-writes/) · [`wal_sync_method`](/parameters/wal-sync-method/) · [`synchronous_commit`](/parameters/synchronous-commit/) · [`wal_buffers`](/parameters/wal-buffers/) · [`commit_delay`](/parameters/commit-delay/)

## References {#references}

- [PostgreSQL 19 Beta 3 — wal_writer_delay](https://www.postgresql.org/docs/19/runtime-config-wal.html#GUC-WAL-WRITER-DELAY)
- [PostgreSQL 19 release notes](https://www.postgresql.org/docs/19/release-19.html)
- [Machine-readable GUC export](/data/guc.jsonl)