ignore_checksum_failure

ignore_checksum_failure — Continues processing after a checksum failure. Observed in PG9.3–19 Beta 3; its last measured boot default is off in PG19 Beta 3, with superuser context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Continues processing after a checksum failure.”

Identity

Type , Valuebool: Upstream pg_settings type
Context , Valuesuperuser: Settable at runtime by a superuser
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueDeveloper Options: Upstream classification
Latest boot value , Valueoff: off

Lifecycle

Fact	Value
First observed	PG9.3
Present in	PG9.3–19 Beta 3
Removed in	No
Introduction commit	`96ef3b8ff1cf` — Allow I/O reliability checks using 16-bit checksums
Commit date	2013-03-22
Discussion	—

Default history

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

How it works

With data checksums enabled, a page checksum mismatch normally aborts the current transaction. ignore_checksum_failure instead emits a warning and attempts to continue if the page header is still sane.

It does not repair the page or prove remaining tuples are valid. Continuing can crash, hide or propagate corruption, and a damaged header still stops access.

The only defensible use is controlled data salvage from an immutable copy after storage and backup recovery options are exhausted. Every read under this mode is suspect evidence, not restored integrity. Its superuser context permits an authorized session change without a server restart.

Tuning advice

Tip

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

Workload	Guidance
OLTP	Never use ignore_checksum_failure as tuning or a steady-state availability setting. Stop writes, preserve immutable copies, exhaust backup/storage repair, document expected data loss, salvage narrowly, rebuild, and validate before any return to service.
OLAP	Read-only analytics does not make ignore_checksum_failure safe: corrupted pages can still poison results or structures. Use only on a disposable salvage copy with explicit acceptance of lost data.
Small nodes	Do not enable ignore_checksum_failure merely because no replica exists. Preserve the original first and seek a clean backup; this switch can convert visible corruption into silent loss.

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: PG9.3–19 Beta 3 unmodified; OLAP: PG9.3–19 Beta 3 unmodified; CRIT: PG9.3–19 Beta 3 unmodified; TINY: PG9.3–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Leaving ignore_checksum_failure 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.

zero_damaged_pages · ignore_invalid_pages · data_checksums · wal_consistency_checking