Hi, On 2021-06-16 12:59:33 +0200, Matthias van de Meent wrote: > PFA my adapted patch that fixes this new-ish issue, and does not > include the (incorrect) assertions in GlobalVisUpdateApply. I've > tested this against the reproducing case, both with and without the > fix in GetOldestNonRemovableTransactionId, and it fails fall into an > infinite loop.
Could you share your testcase? I've been working on a series of patches to address this (I'll share in a bit), and I've run quite a few tests, and didn't hit any infinite loops. > diff --git a/src/backend/access/heap/vacuumlazy.c > b/src/backend/access/heap/vacuumlazy.c > index 4b600e951a..f4320d5a34 100644 > --- a/src/backend/access/heap/vacuumlazy.c > +++ b/src/backend/access/heap/vacuumlazy.c > @@ -1675,6 +1675,12 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams > *params, bool aggressive) > * that any items that make it into the dead_tuples array are simple LP_DEAD > * line pointers, and that every remaining item with tuple storage is > * considered as a candidate for freezing. > + * > + * Note: It is possible that vistest's window moves back from the > + * vacrel->OldestXmin (see ComputeXidHorizons). To prevent an infinite > + * loop where we bounce between HeapTupleSatisfiesVacuum and > + * heap_prune_satisfies_vacuum who disagree on the [almost]deadness of > + * a tuple, we only retry when we know HTSV agrees with HPSV. > */ HTSV is quite widely used because HeapTupleSatisfiesVacuum is quite widely used. HPSV isn't, so it's a bit confusing to use this. Greetings, Andres Freund
