wal_skip_threshold

Definition PG 18 manual

When wal_level is minimal and a transaction commits after creating or rewriting a permanent relation, this setting determines how to persist the new data. If the data is smaller than this setting, write it to the WAL log; otherwise, use an fsync of affected files. Depending on the properties of your storage, raising or lowering this value might help if such commits are slowing concurrent transactions. If this value is specified without units, it is taken as kilobytes. The default is two megabytes (2MB).

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.

Operational considerations

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.

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