XX001ERRORTier 1 — Safe✅ HIGH confidencedata_corrupted
🔴 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
- 1Storage hardware failure (bad disk sectors, failing SSD)
- 2Incomplete or interrupted writes due to power failure without battery-backed write cache
- 3Kernel or filesystem bug causing corrupt writes
- 4RAM errors causing corrupted data before it was written to disk
- 5pg_filedump or direct file manipulation corrupted a data page
- 6Bug in PostgreSQL version (rare)
How to reproduce
Any read operation against a table or index with a corrupted page
SELECT * FROM my_table; -- if a data page is corruptedFix 1: Restore from a known-good backup
Data corruption detected — this is the safest recovery path
-- Stop PostgreSQL, restore from backup, replay WAL to the point before corruptionWhy 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
SET zero_damaged_pages = on;
SELECT * FROM my_table; -- corrupted pages return zeros instead of erroringWhy 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
-- pg_dump -h localhost -U postgres -d mydb -t my_table > salvage.sqlWhy 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
Confidence assessment
✅ HIGH confidence
Critical error code from official PostgreSQL appendix; recovery guidance based on official documentation.
See also
🔗 Related errors
📄 Reference pages