Know whether you could detect page corruption
"invalid page in block" names a file, not a table, and it only appears at all if the cluster can check. Decode the relation, read whether checksums were ever enabled, and verify heap and indexes before a bad page becomes a bad backup.
Problem
What you're actually looking at
The symptom as it shows up on a real server.
Corruption is diagnosed backwards. The error names a filenode path rather than a relation, so the first job is decoding it. Worse, whether you get an error at all depends on a decision made at initdb time: without data checksums PostgreSQL reads a damaged page and returns whatever it holds, so the failure mode is wrong answers rather than a raised error.
A Meridian query starts failing with an invalid page error naming base/16421/3192429. Nobody knows whether that is a table, an index or a TOAST relation, and therefore nobody knows whether a REINDEX would help or is beside the point. Meanwhile the same pages have been flowing into backups and replicas for as long as the damage has existed.
In plain English
PostgreSQL keeps data in 8 kB pages. If one gets damaged — a failing disk, a flipped bit, storage that says a write finished when it did not — the database may hand you an error naming a file on disk rather than a table name, which is not much help at 2am. There is a bigger problem behind that. PostgreSQL only checks whether a page is intact if checksums were switched on when the cluster was first created, and that is not the default. With them off, a damaged page is read and its contents returned as if nothing were wrong, so the symptom is wrong answers rather than an error. So the question worth answering before any of this happens is not "how do I repair a page" — it is "would I even find out". This runbook answers that, decodes the error to a real relation, and checks the heap and indexes while there is still a clean backup to fall back on.
Full runbook for this incident
- The full identify checklist — the exact signals that tell you it's this incident
- Every diagnostic query; PostgreSQL 18 output is attached only to the steps we captured
- The resolution path and the pitfalls that make it worse
- Mitigation steps to stop it recurring, plus a verify-you're-done query
More in this category
Other Observability runbooks
Neighbouring incidents that share the same diagnostic surface.