Re: COPY FREEZE and PD_ALL_VISIBLE - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: COPY FREEZE and PD_ALL_VISIBLE
Date
Msg-id CAA4eK1LsxzgDs3S-4AHH=pGJnheYVXDyebvbxLjkJS1BnN_Gpw@mail.gmail.com
Whole thread Raw
In response to Re: COPY FREEZE and PD_ALL_VISIBLE  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Oct 23, 2015 at 2:46 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Wed, Oct 21, 2015 at 1:31 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> > It turns out it was pretty easy to set PD_ALL_VISIBLE on the new pages,
> > since the code in hio that requests the relation to be extended already has
> > info on the tuple's intended freeze status.
> >
> > Then you just need to refrain from clearing PD_ALL_VISIBLE when that tuple
> > is actually written into the page.  Not only because clearing would defeat
> > the purpose, but also because it will cause an error--apparently the
> > incipient page is not yet in a state where visibilitymap_clear is willing to
> > deal with it.
>
> Wouldn't it be better to instead fill the page with tuples first and
> THEN set PD_ALL_VISIBLE?
>

Ideally that would be better and if we want to do that way, then I think it
needs to be done at end of Copy Freeze operation, also for that we
need to mark the buffer as dirty again (do you see any other way
of achieving the same?).  OTOH, I don't see any harm even if we do it
in the way as done in patch.


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

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
Next
From: Simon Riggs
Date:
Subject: Re: COPY FREEZE and PD_ALL_VISIBLE