On Wed, 16 Jun 2021 at 21:12, Andres Freund <andres@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