On Wed, Jun 9, 2021 at 2:17 AM Andres Freund <and...@anarazel.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/
