Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

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