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  (Peter Geoghegan <pg@bowt.ie>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: BUG: Postgres 14 + vacuum_defer_cleanup_age + FOR UPDATE + UPDATE
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Fixing a couple of buglets in how VACUUM sets visibility map bits