EC
XX001
PostgreSQLERRORCommonInternal ErrorHIGH confidence

data_corrupted

Production Risk

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
trigger — this will error
SELECT * FROM my_table;  -- if a data page is corrupted

expected output

ERROR:  XX001: invalid page header in block 42 of relation base/16384/12345

Fix 1

Restore from a known-good backup

WHEN Data corruption detected — this is the safest recovery path

Restore from a known-good backup
-- 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

WHEN Backup is unavailable and data loss is acceptable for some rows

Use zero_damaged_pages as a temporary workaround
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

WHEN Attempting to recover as much data as possible before restore

Run pg_dump to extract salvageable data
-- 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

It silently skips corrupt pages, hiding further corruption and causing data loss

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

Data corruption can spread; immediate backup restore is the safest response

Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev

← All PostgreSQL errors