Re: BUG: Postgres 14 + vacuum_defer_cleanup_age + FOR UPDATE + UPDATE
От | Peter Geoghegan |
---|---|
Тема | Re: BUG: Postgres 14 + vacuum_defer_cleanup_age + FOR UPDATE + UPDATE |
Дата | |
Msg-id | CAH2-Wzkrh1OmRy=xNQbx4Yb708j152tZ-oPKS1S7fNURVxKTOg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG: Postgres 14 + vacuum_defer_cleanup_age + FOR UPDATE + UPDATE (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG: Postgres 14 + vacuum_defer_cleanup_age + FOR UPDATE + UPDATE
|
Список | pgsql-hackers |
On Sat, Feb 4, 2023 at 2:57 AM Andres Freund <andres@anarazel.de> wrote: > Is there a good way to make breakage in the page recycling mechanism > visible with gist? I guess to see corruption, I'd have to halt a scan > before a page is visited with gdb, then cause the page to be recycled > prematurely in another session, then unblock the first? Which'd then > visit that page, thinking it to be in a different part of the tree than > it actually is? Yes. This bug is similar to an ancient nbtree bug fixed back in 2012, by commit d3abbbeb. > which clearly doesn't seem right. > > I just can't quite judge how bad that is. It's really hard to judge, even if you're an expert. We're talking about a fairly chaotic scenario. My guess is that there is a very small chance of a very unpleasant scenario if you have a GiST index that has regular page deletions, and if you use vacuum_defer_cleanup_age. It's likely that most GiST indexes never have any page deletions due to the workload characteristics. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: