Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae - Mailing list pgsql-bugs

From Andres Freund
Subject Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
Date
Msg-id 20240516202949.mln62sfh67xnc2fe@awork3.anarazel.de
Whole thread Raw
In response to Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
List pgsql-bugs
Hi,

On 2024-05-16 16:13:35 -0400, Peter Geoghegan wrote:
> On Thu, May 16, 2024 at 3:39 PM Andres Freund <andres@anarazel.de> wrote:
> > Melanies reproducer works because there are catalog accesses that can trigger
> > a recomputation of fuzzy horizon. For testing the "easy" window for that is
> > the vac_open_indexes() < 16, because it happens after determining the horizon,
> > but before actually vacuuming.
>
> What about the call to GetOldestNonRemovableTransactionId() that takes
> place in _bt_pendingfsm_finalize()?

Ah, good catch! That'd do it.



> > Now I wonder if there is some codepath triggering catalog lookups during bulk
> > delete.
>
> I don't think that there's any rule that says that VACUUM cannot do
> catalog lookups during bulk deletions. B-Tree page deletion needs to
> generate an insertion scan key, so that it can "refind" a page
> undergoing deletion. That might require catalog lookups.

I'm not saying there's a hard rule against it. Just that there wasn't an
immediately apparent, nor immediately observable, path for it. As I didn't see
the path to the horizon recomputation, I didn't know how a btbulkdelete in the
middle of the scan would potentially trigger the problem.

Greetings,

Andres Freund



pgsql-bugs by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
Next
From: Peter Geoghegan
Date:
Subject: Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae