Re: Freeze avoidance of very large table.

On 2015-04-22 00:15:53 +0900, Sawada Masahiko wrote:
> On Wed, Apr 22, 2015 at 12:02 AM, Andres Freund <andres(at)anarazel(dot)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