Parameter · Developer Options
ignore_checksum_failure
Continues processing after a checksum failure. Detection of a checksum failure normally causes PostgreSQL to report an error, aborting the current transaction. Setting ignore_checksum_failure to true causes the system to ignore the failure (but still report a warning), and continue processing. This behavior could cause crashes or other serious problems. Only has an effect if checksums are enabled.
- Default:
off - Type: bool
- Applies: Session (superuser)
In plain words
With data checksums enabled, every page carries a fingerprint. When a page read from disk does not match its fingerprint, PostgreSQL refuses to use it and the query fails. This switch makes PostgreSQL warn and use the page anyway.
It can help you read out the rest of a slightly damaged table, but the page itself may contain garbage that crashes the server or spreads into other data.
For DBAs and operators
Only meaningful when data_checksums is on (the default for new clusters since PostgreSQL 18). Captured on 18.6 after flipping 4 bytes in the row area of block 0 (header still valid):
LOG: page verification failed, calculated checksum 61435 but expected 19117CONTEXT: I/O worker executing I/O on behalf of process 1986ERROR: invalid page in block 0 of relation "base/5/24695"With SET ignore_checksum_failure = on the same read gives
and the query returns the rows, including whatever the flipped bytes now say. Once the page is in shared buffers it is not checked again, so later queries (even in other sessions) see it without warnings until it is evicted. If the header itself is broken, this setting does not help: you still get invalid page, which only zero_damaged_pages bypasses.
Checksum failures are counted in pg_stat_database.checksum_failures and checksum_last_failure; check them during any corruption ticket. pg_checksums --check (server stopped) or pg_amcheck show the extent of the damage.
Danger. The page is used as-is: wrong values may be returned, and a damaged tuple can crash the backend or be copied into new rows, indexes or backups. Take a file-level copy of the data directory (or of the affected files) before touching it, and turn it off again as soon as you are done.
How to change it
A superuser (or a role granted SET) can change it per session with SET.
See it in context
Related parameters
zero_damaged_pages data_checksums ignore_invalid_pages full_page_writes