Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae

Поиск
Список
Период
Сортировка
Искать
От
Andres Freund
Тема
Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
Дата
в 20:29:49
Msg-id
20240516202949.mln62sfh67xnc2fe@awork3.anarazel.de
Ответ на
Список
Дерево обсуждения
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
Дата:
FAQ