Re: BUG #17245: Index corruption involving deduplicated entries

On Thu, Oct 28, 2021 at 2:36 PM Andres Freund <andres@anarazel.de> wrote:
> > * The transaction ID 365637 is very over-represented, appearing in
> > several corrupt heap tuple headers, located across several heap pages.
> >
> > * Its "neighbor" transaction ID is 365638, which appears once more. To
> > me this suggests some kind of confusion with an OldestXmin style
> > cutoff during VACUUM.
>
> I'm not quite following this bit, could you expand on that?

I think it's odd that we use both an GlobalVisState and an OldestXmin
for VACUUM's first pass over the heap as of Postgres 14 (before the
snapshot scalability stuff, we just had OldestXmin). I have in the
past wondered if that might cause problems. For example, how do we
know that GlobalVisState won't ever slightly disagree with OldestXmin?
For example, about which tuples are dead, rather than recently dead?

This scenario reminds me of the tupgone mess that used to exist inside
the code that's called lazy_scan_prune() in Postgres 14. Actually, I
probably thought of when working on removing tupgone (which happened
in commit 8523492d4e).

I am of course just guessing. Perhaps this is unfair.

-- 
Peter Geoghegan