DB Internals AtlasPostgreSQL 18.6 Home About

Parameter · Developer Options

ignore_invalid_pages

Continues recovery after an invalid pages failure. Detection of WAL records having references to invalid pages during recovery causes PostgreSQL to raise a PANIC-level error, aborting the recovery. Setting "ignore_invalid_pages" to true causes the system to ignore invalid page references in WAL records (but still report a warning), and continue recovery. This behavior may cause crashes, data loss, propagate or hide corruption, or other serious problems. Only has an effect during recovery or in standby mode.

  • Default: off
  • Type: bool
  • Applies: Restart required

In plain words

During crash recovery or on a standby, PostgreSQL replays WAL. If WAL refers to pages that are missing from the data files, something is inconsistent, so recovery stops with a PANIC. This switch turns that PANIC into a warning so the server can start anyway.

It is an emergency door to get a damaged cluster up long enough to dump data, not a fix.

For DBAs and operators

While replaying, the startup process remembers each reference to a page that does not exist (for example because the file was truncated or lost). Some are legitimate and are cleared later (the table was dropped or truncated further on in WAL). If any remain when recovery reaches consistency, it fails with

WARNING: page 5 of relation base/16384/16390 does not existPANIC: WAL contains references to invalid pages

With ignore_invalid_pages = on the warnings are still logged but recovery continues. It only has an effect during recovery or in standby mode, and it can only be set at server start.

Typical causes in support cases: a data directory restored without all files (a broken copy, a missed tablespace, an incomplete snapshot), files deleted by hand, or storage-level corruption. Fix the cause (restore again from a good base backup plus WAL) whenever possible; use this only to rescue data and then dump/restore into a fresh cluster.

Danger. Recovery that ignores invalid pages may crash later, lose data, or hide and propagate corruption. 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

Change in postgresql.conf or ALTER SYSTEM, then restart the server.

See it in context

Crash recovery Startup process Write-ahead log (WAL)

Related parameters

zero_damaged_pages ignore_checksum_failure recovery_target_action full_page_writes

All Developer Options parameters