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)
Список
Дерево обсуждения
Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune() Alena Rybakina <lena.ribackina@yandex.ru>
Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune() Matthias van de Meent <boekewurm+postgres@gmail.com>
Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune() Alena Rybakina <lena.ribackina@yandex.ru>
Hi, On 2024-05-16 16:13:35 -0400, Peter Geoghegan wrote: > On Thu, May 16, 2024 at 3:39 PM Andres Freund 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 по дате отправления
От: Peter Geoghegan
Дата:
От: Peter Geoghegan
Дата: