Re: Fixing a couple of buglets in how VACUUM sets visibility map bits
От | Andres Freund |
---|---|
Тема | Re: Fixing a couple of buglets in how VACUUM sets visibility map bits |
Дата | |
Msg-id | 20230109194443.vnkvury7ee2aqb27@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Fixing a couple of buglets in how VACUUM sets visibility map bits (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Fixing a couple of buglets in how VACUUM sets visibility map bits
|
Список | pgsql-hackers |
Hi, On 2023-01-08 16:27:59 -0800, Peter Geoghegan wrote: > On Sun, Jan 8, 2023 at 3:53 PM Andres Freund <andres@anarazel.de> wrote: > > How? > > See the commit message for the scenario I have in mind, which involves > a concurrent HOT update that aborts. I looked at it. I specifically was wondering about this part of it: > One of the calls to visibilitymap_set() during VACUUM's initial heap > pass could unset a page's all-visible bit during the process of setting > the same page's all-frozen bit. Which I just don't see as possible, due to visibilitymap_set() simply never unsetting bits. I think that's just an imprecise formulation though - the problem is that we can call visibilitymap_set() with just VISIBILITYMAP_ALL_FROZEN, even though VISIBILITYMAP_ALL_VISIBLE was concurrently unset. ISTM that we ought to update all_visible_according_to_vm from PageIsAllVisible() once we've locked the page. Even if we avoid this specific case, it seems a recipe for future bugs to have a potentially outdated variable around. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: