On Wed, Jul 9, 2025 at 1:02 PM Erik Johnston <erikj@element.io> wrote:
> To recap: the situation is that, looking at our backup from 2025-06-26 via pageinspect, we have btree index rows
whichpoint to either non-existent heap TIDs, or to heap TIDs with data which does not correspond to the index row. In
factit looks like we have entire index pages which point only to non-existent heap TIDs.
This is a generic symptom of corruption. You can see this sort of
thing whenever (say) the storage lies about fsync having flushed
everything to disk. The index might still contain TIDs that point to
heap pages that existed before the crash, that didn't survive crash
recovery. It's quite likely that those same TIDs will be used for
wholly unrelated logical rows when the application inserts a little
more data.
> Empirically, and surprisingly to us, when one does a SELECT from an index entry that points to a non-existent TID,
theindex entry is quietly ignored.
>
> We therefore suspect that this index corruption has been present for some time (possibly years); more recently those
non-existentheap TIDs have been recycled, and that is when we have noticed the effects of the problem.
That sounds plausible.
--
Peter Geoghegan
