Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
От | Peter Geoghegan |
---|---|
Тема | Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae |
Дата | |
Msg-id | CAH2-WzkpqV5hUUnbn1BsMaZt45EMA6RNeyP62cuZ3C-XagAjUQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
|
Список | pgsql-bugs |
On Thu, May 16, 2024 at 3:39 PM Andres Freund <andres@anarazel.de> wrote: > Hm, were the cases you observed that way using parallel vacuuming? And what > index types were involved? They definitely didn't use parallel VACUUM, since autovacuum was involved in all cases. Only B-Tree indexes were involved. There were plenty of index page deletions involved, since the underlying workload involved bulk deletions. Deletions that seemed to leave every heap page without any heap tuples. Partitioning also happened to be involved. No particular reason to suspect that that matters, though. > 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()? > 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. -- Peter Geoghegan
В списке pgsql-bugs по дате отправления: