Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

On Tue, Jun 8, 2021 at 5:27 AM Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
> > (gdb) p *vacrel
> > $56 = {... OldestXmin = 926025113, ...}
> >
> > (gdb) p GlobalVisCatalogRels
> > $57 = {definitely_needed = {value = 926025113}, maybe_needed = {value = 926025112}}
>
> This maybe_needed is older than the OldestXmin, which indeed gives us
> this problematic behaviour:

Good catch.

> 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.

Following up from my email from an hour ago here. Since I have no
reason to suspect HeapTupleSatisfiesVacuum (per the earlier analysis),
this is very much starting to look like a
heap_prune_satisfies_vacuum() problem. And therefore likely a problem
in the snapshot scalability work.

Note that GlobalVisCatalogRels.maybe_needed is 926025112, which
doesn't match OldestXmin in VACUUM (that's 926025113). Though both
GlobalVisDataRels.definitely_needed and GlobalVisDataRels.maybe_needed
*are* 926025113, and therefore agree with VACUUM's OldestXmin. But
this is pg_statistic we're vacuuming, and so GlobalVisCatalogRels is
what matters.

> 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.

Exactly.

-- 
Peter Geoghegan