Re: Freeze avoidance of very large table.

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Freeze avoidance of very large table.
Дата
Msg-id CAA4eK1+R1Fk2Ou89hvgy7-zTRhmQS2D68YHD7r58axukN198JQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Freeze avoidance of very large table.  (Sawada Masahiko <sawada.mshk@gmail.com>)
Ответы Re: Freeze avoidance of very large table.  (Sawada Masahiko <sawada.mshk@gmail.com>)
Список pgsql-hackers
On Fri, Jul 3, 2015 at 1:55 PM, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
>
> On Fri, Jul 3, 2015 at 1:23 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> > On 2 July 2015 at 16:30, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
> >
> >>
> >> Also, the flags of each heap page header might be set PD_ALL_FROZEN,
> >> as well as all-visible
> >
> >
> > Is it possible to have VM bits set to frozen but not visible?
> >
> > The description makes those two states sound independent of each other.
> >
> > Are they? Or not? Do we test for an impossible state?
> >
>
> It's impossible to have VM bits set to frozen but not visible.

In patch, during Vacuum first the frozen bit is set and then the visibility
will be set in a later operation, now if the crash happens between those
2 operations, then isn't it possible that the frozen bit is set and visible
bit is not set?

> These bit are controlled independently. But eventually, when
> all-frozen bit is set, all-visible is also set.
>

Yes, during normal operations it will happen that way, but I think there
are corner cases where that assumption is not true.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Memory Accounting v11
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Re: Foreign join pushdown vs EvalPlanQual