Re: Reviewing freeze map code

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Reviewing freeze map code
Дата
Msg-id 20160716013203.gni5x6jjnmjajvc6@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Reviewing freeze map code  (Andres Freund <andres@anarazel.de>)
Ответы Re: Reviewing freeze map code  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On 2016-07-13 23:06:07 -0700, Andres Freund wrote:
> > +        /* Clear only the all-frozen bit on visibility map if needed */
> > +        if (PageIsAllVisible(BufferGetPage(buffer)) &&
> > +            VM_ALL_FROZEN(relation, block, &vmbuffer))
> > +        {
> > +            visibilitymap_clear_extended(relation, block, vmbuffer,
> > +                                         VISIBILITYMAP_ALL_FROZEN);
> > +        }
> > +
> 
> FWIW, I don't think it's worth introducing visibilitymap_clear_extended.
> As this is a 9.6 only patch, i think it's better to change
> visibilitymap_clear's API.

Besides that easily fixed issue, the code also has the significant issue
that it's only performing the the visibilitymap processing in the
BLK_NEEDS_REDO case. But that's not ok, because both in the BLK_RESTORED
and the BLK_DONE cases the visibilitymap isn't guaranteed (or even
likely in the former case) to have been updated.

I think we have two choices how to deal with that: First, we can add a
new flags variable to xl_heap_lock similar to
xl_heap_insert/update/... and bump page magic, or we can squeeze the
information into infobits_set.  The latter seems fairly ugly, and
fragile to me; so unless somebody protests I'm going with the former. I
think due to padding the additional byte doesn't make any size
difference anyway.

Regards,

Andres



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: visibilitymap_clear()s in vacuumlazy.c aren't WAL logged
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Regression tests vs existing users in an installation