PG
PRO
XX001ERRORTier 1 — Safe✅ HIGH confidence

data_corrupted

Category: Internal ErrorVersions: All PostgreSQL versions

🔴 Production Risk Error

Critical — data corruption requires immediate action; restore from backup and investigate storage hardware

What this means

PostgreSQL detected corruption in on-disk data pages or heap tuples. This is a critical error indicating the stored data does not pass internal consistency checks.

Why it happens

  1. 1Storage hardware failure (bad disk sectors, failing SSD)
  2. 2Incomplete or interrupted writes due to power failure without battery-backed write cache
  3. 3Kernel or filesystem bug causing corrupt writes
  4. 4RAM errors causing corrupted data before it was written to disk
  5. 5pg_filedump or direct file manipulation corrupted a data page
  6. 6Bug in PostgreSQL version (rare)

How to reproduce

Any read operation against a table or index with a corrupted page

trigger — this will ERROR
SELECT * FROM my_table;  -- if a data page is corrupted
ERROR: XX001: invalid page header in block 42 of relation base/16384/12345

Fix 1: Restore from a known-good backup

Data corruption detected — this is the safest recovery path

fix
-- Stop PostgreSQL, restore from backup, replay WAL to the point before corruption

Why this works

Replaces corrupted files with clean copies; safest and most reliable recovery

Fix 2: Use zero_damaged_pages as a temporary workaround

Backup is unavailable and data loss is acceptable for some rows

fix
SET zero_damaged_pages = on;
SELECT * FROM my_table;  -- corrupted pages return zeros instead of erroring

Why this works

Allows reads to continue by silently skipping corrupt pages; data in those pages is lost

Fix 3: Run pg_dump to extract salvageable data

Attempting to recover as much data as possible before restore

fix
-- pg_dump -h localhost -U postgres -d mydb -t my_table > salvage.sql

Why this works

Dumps non-corrupted rows; skip corrupt pages with zero_damaged_pages=on

What not to do

Do not continue running PostgreSQL with zero_damaged_pages=on permanently

Why it's wrong: It silently skips corrupt pages, hiding further corruption and causing data loss

Do not ignore XX001 errors — treat them as a storage emergency

Why it's wrong: Data corruption can spread; immediate backup restore is the safest response

Dangerous variant

⚠️ Warning

zero_damaged_pages=on bypasses corruption checks and silently returns zeros — always causes data loss for the affected pages

Sources

📚 Official docs: https://www.postgresql.org/docs/current/runtime-config-developer.html#GUC-ZERO-DAMAGED-PAGES

🔧 Source ref: https://www.postgresql.org/docs/current/errcodes-appendix.html

📖 Further reading:

📖 Further reading:

Confidence assessment

✅ HIGH confidence

Critical error code from official PostgreSQL appendix; recovery guidance based on official documentation.

See also

📄 Reference pages

PostgreSQL backup and recoverypg_filedump
⚙️ This error reference was generated with AI assistance and reviewed for accuracy. Examples are provided to illustrate common scenarios and may not cover every case. Always test fixes in a development environment before applying to production. Spotted an error? Suggest a correction →