ignore_checksum_failure

Definition PG 18 manual

Only has effect if data checksums are enabled.

Detection of a checksum failure during a read normally causes PostgreSQL to report an error, aborting the current transaction. Setting ignore_checksum_failure to on causes the system to ignore the failure (but still report a warning), and continue processing. This behavior may cause crashes, propagate or hide corruption, or other serious problems. However, it may allow you to get past the error and retrieve undamaged tuples that might still be present in the table if the block header is still sane. If the header is corrupt an error will be reported even if this option is enabled. The default setting is off. Only superusers and users with the appropriate SET privilege can change this setting.

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.

Operational considerations

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.

Workload guidance

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.

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.

SMALL: 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.