ignore_invalid_pages

ignore_invalid_pages — Continues recovery after an invalid pages failure. Observed in PG13–19 Beta 3; its last measured boot default is off in PG19 Beta 3, with postmaster context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Continues recovery after an invalid pages failure.”

Identity

Type , Valuebool: Upstream pg_settings type
Context , Valuepostmaster: Requires a server restart
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	PG13
Present in	PG13–19 Beta 3
Removed in	No
Introduction commit	`41c184bc642b` — Add GUC ignore_invalid_pages.
Commit date	2020-01-22
Discussion	thread 1

Default history

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

How it works

During recovery, WAL references to invalid pages normally cause PANIC and stop recovery. ignore_invalid_pages logs a warning and continues past those references.

The startup-only setting has effect only in recovery or standby mode. Skipping redo can lose data, propagate corruption, and leave structures internally inconsistent even if the server reaches a running state.

It is an emergency salvage mechanism after preserving evidence and exhausting correct restore paths. A server that starts under it must not be considered healthy or promoted into normal service. Its postmaster context fixes the value at server start; changing it requires a restart.

Tuning advice

Tip

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

Workload	Guidance
OLTP	Never use ignore_invalid_pages 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_invalid_pages 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_invalid_pages 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: PG13–19 Beta 3 unmodified; OLAP: PG13–19 Beta 3 unmodified; CRIT: PG13–19 Beta 3 unmodified; TINY: PG13–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

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

ignore_checksum_failure · zero_damaged_pages · restore_command · wal_consistency_checking