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

From Andres Freund
Subject Re: Freeze avoidance of very large table.
Date
Msg-id 20150421154052.GK14483@alap3.anarazel.de
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Sawada Masahiko <sawada.mshk@gmail.com>)
List pgsql-hackers
On 2015-04-22 00:15:53 +0900, Sawada Masahiko wrote:
> On Wed, Apr 22, 2015 at 12:02 AM, Andres Freund <andres@anarazel.de> wrote:
> > On 2015-04-21 23:59:45 +0900, Sawada Masahiko wrote:
> >> The page as frozen could have the dead tuple for now, but I think to change
> >> to that the frozen page guarantees that page is all frozen *and* all
> >> visible.
> >
> > It shouldn't. That'd potentially cause corruption after a wraparound. A
> > tuple's visibility might change due to that.
> 
> The page as frozen could have some dead tuples, right?

Well, we right now don't really freeze pages, but tuples. But in what
you described above that could happen.

> I think we should to clear a bit of FrozenMap (and flag of page
> header) on delete operation, and a bit is set only by vacuum.

Yes.

> So accordingly, the page as frozen guarantees that all frozen and all
> visible?

I think that's how it has to be, yes.

I *do* wonder if we shouldn't redefine the VM to also contain
information about the frozenness. Having two identically structured maps
that'll often both have to be touched at the same time isn't
nice. Neither is adding another fork.  Given the size of the files
pg_upgrade could be made to rewrite them.  The bigger question is
probably how bad that'd be for index-only efficiency.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Asif Naeem
Date:
Subject: Re: Fix broken Install.bat when target directory contains a space
Next
From: Stephen Frost
Date:
Subject: Re: preprocess_targetlist and inheiritance