Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
| От | Peter Geoghegan |
|---|---|
| Тема | Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM? |
| Дата | |
| Msg-id | CAH2-WzkHPgsBBvGWjz=8PjNhDefy7XRkDKiT5NxMs-n5ZCf2dA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM? (Andrey Borodin <x4mmm@yandex-team.ru>) |
| Ответы |
Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM? |
| Список | pgsql-hackers |
On Fri, Nov 5, 2021 at 3:26 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote: > > 4 нояб. 2021 г., в 20:58, Peter Geoghegan <pg@bowt.ie> написал(а): > > That's a pretty unlikely scenario. And even > > if it happened it would only happen once (until the next time we get > > unlucky). What are the chances of somebody noticing a more or less > > once-off, slightly wrong answer? > > I'd say next to impossible, yet not impossible. Or, perhaps, I do not see protection from this. I think that that's probably all correct -- I would certainly make the same guess. It's very unlikely to happen, and when it does happen it happens only once. > Moreover there's a "microvacuum". It kills tuples with BUFFER_LOCK_SHARE. AFAIU it should take cleanup lock on buffer too? No, because there is no heap vacuuming involved (because that doesn't happen outside lazyvacuum.c). The work that VACUUM does inside lazy_vacuum_heap_rel() is part of the problem here -- we need an interlock between that work, and index-only scans. Making LP_DEAD items in heap pages LP_UNUSED is only ever possible during a VACUUM operation (I'm sure you know why). AFAICT there would be no bug at all without that detail. I believe that there have been several historic reasons why we need a cleanup lock during nbtree VACUUM, and that there is only one remaining reason for it today. So the history is unusually complicated. But AFAICT it's always some kind of "interlock with heapam VACUUM" issue, with TID recycling, with no protection from our MVCC snapshot. I would say that that's the "real problem" here, when I get to first principles. Attached draft patch attempts to explain things in this area within the nbtree README. There is a much shorter comment about it within vacuumlazy.c. I am concerned about GiST index-only scans themselves, of course, but I discovered this issue when thinking carefully about the concurrency rules for VACUUM -- I think it's valuable to formalize and justify the general rules that index access methods must follow. We can talk about this some more in NYC. See you soon! -- Peter Geoghegan
Вложения
В списке pgsql-hackers по дате отправления: