On Wed, 16 Jun 2021 at 21:12, Andres Freund <and...@anarazel.de> wrote: > > 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.
* Failst _to_ fall into an infinite loop. Sorry, failed to add a "to". It passes tests > 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. Basically, I've tested using the test case shared earlier; 2 sessions spamming connections with "reindex concurrently some_index" and "analyze pg_attribute" against the same database. > > > > 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. Sure. I thought it was fine to shorten, as the full function name was just named the line above and it's a long name, but I'm fine with either. Kind regards, Matthias
