On Mon, Sep 21, 2020 at 1:11 PM Andres Freund <and...@anarazel.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...@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
