Re: recovering from "found xmin ... from before relfrozenxid ..."

On Mon, Sep 21, 2020 at 1:11 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I'm not sure I really understand how that's happening, because surely
> > HOT chains and non-HOT chains are pruned by the same code, but it
> > doesn't sound good.
>
> Not necessarily, unfortunately:
>
> case HEAPTUPLE_DEAD:

> So if e.g. a transaction aborts between the heap_page_prune and this
> check the pruning behaviour depends on whether the tuple is part of a
> HOT chain or not.

I have a proposal that includes removing this "tupgone = true" special case:

https://postgr.es/m/CAH2-Wzm7Y=_g3FjVHv7a85AfUbuSYdggDnEqN1hodVeOctL+Ow@mail.gmail.com

Of course this won't change the fact that vacuumlazy.c can disagree
with pruning about what is dead -- that is a necessary consequence of
having multiple HTSV calls for the same tuple in vacuumlazy.c (it can
change in the presence of concurrently aborted transactions). But
removing the "tupgone = true" special case does seem much more
consistent, and simpler overall. We have lots of code that is only
needed to make that special case work. For example, the whole idea of
a dedicated XLOG_HEAP2_CLEANUP_INFO record for recovery conflicts can
go -- we can get by with only XLOG_HEAP2_CLEAN records from pruning,
IIRC.

Have I missed something? The special case in question seems pretty
awful to me, so I have to wonder why somebody else didn't remove it
long ago...

--
Peter Geoghegan