wal_skip_threshold

wal_skip_threshold sets the minimum size of new file to fsync instead of writing WAL. It is a user setting present in PG13–18; the latest recorded boot default is 2 MiB.

Note

Fact — official short description: “Minimum size of new file to fsync instead of writing WAL.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valueuser: Settable by an ordinary user
Unit , ValuekB: Raw unit
Range , Value0 – 2147483647: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueWrite-Ahead Log / Settings: Upstream classification
Latest boot value , Value2048: 2 MiB

Lifecycle

Fact	Value
First observed	PG13
Present in	PG13–19 Beta 3
Removed in	No
Introduction commit	`cb2fd7eac285` — Skip WAL for new relfilenodes, under wal_level=minimal.
Commit date	2020-03-21
Discussion	thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG13–19 Beta 3	`2048`	`kB`	2 MiB

How it works

Minimum size of new file to fsync instead of writing WAL. It can be changed at session scope, so different sessions may observe different behavior.

Only at wal_level=minimal, creating or rewriting a permanent relation can either WAL-log its new data or fsync the files directly. This threshold chooses fsync for larger relations and has no effect at replica or logical levels.

Monitor and change wal_skip_threshold together with commit_delay, commit_siblings, fsync. Validate on the relevant server role and real workload, then use its user 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_skip_threshold 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	Unmodified	—	—
OLAP	Unmodified	—	—
CRIT	Unmodified	—	—
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG13–19 Beta 3 unmodified; OLAP: PG13–19 Beta 3 unmodified; CRIT: PG13–19 Beta 3 unmodified; TINY: PG13–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Tuning it at wal_level=replica or logical, where the setting has no effect.
Applying it to ordinary row changes even though it concerns newly created or rewritten relation files.
Reading an unqualified value as bytes instead of kilobytes.
Choosing fsync versus WAL logging without benchmarking the actual storage and concurrent-commit impact.

commit_delay · commit_siblings · fsync · full_page_writes · synchronous_commit · wal_buffers