Re: BUG #17245: Index corruption involving deduplicated entries

Hi,

On 2021-10-28 10:16:35 -0700, Peter Geoghegan wrote:
> Your heap page (page 0 of the "page" heap relation) was very
> interesting. I saw that the TID that is incorrectly repeated in the
> index "page_len" is marked LP_UNUSED in the heap page. It's one of
> only two such TIDs/line pointers on your heap/table page, out of 61
> total, so I doubt that this is a coincidence. That's why I'm asking
> for more heap pages -- I would like to verify that this is a
> consistent thing, and not just a remarkable coincidence.

This makes me wonder if the issue could be that we're loosing writes / that
something is reading old page versions (e.g. due to filesystem bug). If both
heap and index are vacuumed, but the index write is lost, this'd be what we
see, right?

Another way this could happen is if we got the wrong relation size for either
index or table, and a vacuum scan doesn't scan the whole table or index.


I've not yet read the whole thread, but if not done, it seems like a good idea
to use pg_waldump and grep for changes to the relevant heap / index
pages. That might give us more information about what could have happened.


> Now this is looking like a problem in VACUUM (pruning?), not a CREATE
> INDEX thing. It looks like somehow an item that should be LP_DEAD ends
> up being LP_UNUSED during pruning. I have CC'd Andres, to get his
> thoughts on this.

Hm.

There were a fair bit of changes around the separation between heap and index
vacuuming in 14. I wonder if there's potentially something broken around
repeatedly vacuuming the heap without doing index vacuums or such.

It's also possible that there's something wrong in that darned path that
handles recently-dead tuples.

Greetings,

Andres Freund