wal_consistency_checking

Definition PG 18 manual

This parameter is intended to be used to check for bugs in the WAL redo routines. When enabled, full-page images of any buffers modified in conjunction with the WAL record are added to the record. If the record is subsequently replayed, the system will first apply each record and then test whether the buffers modified by the record match the stored images. In certain cases (such as hint bits), minor variations are acceptable, and will be ignored. Any unexpected differences will result in a fatal error, terminating recovery.

The default value of this setting is the empty string, which disables the feature. It can be set to all to check all records, or to a comma-separated list of resource managers to check only records originating from those resource managers. Currently, the supported resource managers are heap, heap2, btree, hash, gin, gist, sequence, spgist, brin, and generic. Extensions may define additional resource managers. Only superusers and users with the appropriate SET privilege can change this setting.

How it works

wal_consistency_checking names WAL resource managers whose redo routines should be verified. For selected records, PostgreSQL includes full-page images and after replay compares the resulting buffers with those images.

Unexpected differences terminate recovery with a fatal error; known nondeterministic differences such as some hint bits are handled specially. all enables every supported resource manager.

The added full-page images can greatly increase WAL volume and replay work. This finds redo implementation bugs; it is not a general on-disk checksum, backup verification, or corruption repair tool. Its superuser context permits an authorized session change without a server restart.

Operational considerations

Leaving wal_consistency_checking enabled after the bounded diagnostic or recovery task.

Running the experiment on the only copy of production data.

Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.

Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Workload guidance

OLAP: Long analytical runs can amplify wal_consistency_checking's debug overhead and artifacts. Prefer standard EXPLAIN and statistics first, and isolate any developer experiment from normal users.

OLTP: Do not tune production OLTP with wal_consistency_checking. Enable it only for a bounded reproduction with an owner, log/disk budget, rollback condition, and evidence-capture plan; restore the default immediately afterward.

SMALL: Keep wal_consistency_checking at its upstream default. A small host has less spare CPU, disk, connection, and log capacity for developer instrumentation.