Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
От | Andres Freund |
---|---|
Тема | Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae |
Дата | |
Msg-id | 20240516202949.mln62sfh67xnc2fe@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae |
Список | 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 по дате отправления: