Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

On Wed, Jun 9, 2021 at 2:17 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2021-06-08 14:27:14 +0200, Matthias van de Meent wrote:
> > heap_prune_satisfies_vacuum considers 1 more transaction to be
> > unvacuumable, and thus indeed won't vacuum that tuple that
> > HeapTupleSatisfiesVacuum does want to be vacuumed.
> >
> > The new open question is now: Why is
> > GlobalVisCatalogRels->maybe_needed < OldestXmin? IIRC
> > GLobalVisCatalogRels->maybe_needed is constructed from the same
> > ComputeXidHorizonsResult->catalog_oldest_nonremovable which later is
> > returned to be used in vacrel->OldestXmin.
>
> The horizon used by pruning is only updated once per transaction (well,
> approximately). What presumably is happening is that the retry loop is
> retrying, without updating the horizon, therefore the same thing is
> happening over and over again?

When we calculated vacrel->OldestXmin in vacuum_set_xid_limits(),
vacrel->OldestXmin and GlogalVisCatalogRels->maybe_needed must have
been the same value. That is, those were 926025113. After that,
vacrel->OldestXmin is not changed throughout lazy vacuum whereas
GlobalVisCatalogRels->maybe_needed could be updated (right?). Is there
any chance that GlobalVisCatalogRels->maybe_needed goes backward? For
example, a case like where when re-calculating
catalog_oldest_nonremovable (i.g. updating
GlobalVisCatalogRels->maybe_needed) we take a process into account who
has an old XID but was ignored last time for some reason (e.g., its
statusFlag).

Regards,

--
Masahiko Sawada
EDB: https://www.enterprisedb.com/