Re: Freeze avoidance of very large table. - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Freeze avoidance of very large table.
Date
Msg-id CAA4eK1+R1Fk2Ou89hvgy7-zTRhmQS2D68YHD7r58axukN198JQ@mail.gmail.com
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Sawada Masahiko <sawada.mshk@gmail.com>)
Responses Re: Freeze avoidance of very large table.  (Sawada Masahiko <sawada.mshk@gmail.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Memory Accounting v11
Next
From: Etsuro Fujita
Date:
Subject: Re: Foreign join pushdown vs EvalPlanQual