Re: CLUSTER FREEZE

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Thomas Munro <munro(at)ip9(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CLUSTER FREEZE
Date: 2013-11-18 08:22:58
Message-ID: CAApHDvpSbHXG4LGZO8hgbEsAuqNUW1+NQO4ZTjcf9HPKsbekhA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 30, 2013 at 3:32 AM, Andres Freund <andres(at)2ndquadrant(dot)com>wrote:

> On 2013-10-25 09:26:29 -0400, Robert Haas wrote:
> > > In any case, it's very far from obvious to me that CLUSTER ought
> > > to throw away information by default, which is what you're proposing.
> >
> > I find it odd to referring to this as throwing away information. I
> > know that you have a general concern about throwing away XIDs that are
> > still needed for forensic purposes, but that is clearly the ONLY
> > purpose that those XIDs serve, and the I/O advantages of freezing by
> > default could be massive for many of our users. What's going to
> > happen in practice is that experienced users will simply recommend
> > CLUSTER FREEZE rather than plain CLUSTER, and you won't have the
> > forensic information *anyway*.
>
> I think we should just apply your "preserve forensic information when
> freezing" patch. Then we're good to go without big arguments ;)
>
>
Ok, here's a recap on the thread as I see it now.

1. Thomas wrote the patch with the idea that FREEZE could be an option for
cluster to freeze the tuples during the cluster operation, which would save
a vacuum freeze somewhere down the line. Sounds like a good idea.
2. Robert introduced the idea that this perhaps could be the default option
for cluster.
3. Tom highlighted that making freeze the default would wipe out xmin
values so they wouldn't be available to any forensics which might to take
place in the event of a disaster.
4. Andres mentioned that we might want to wait for a patch which Robert has
been working on which, currently I don't know much about but it sounds like
it freezes without setting xmin to frozenXid?
5. Robert stated that he's not had much time to work on this patch due to
having other commitments.

In the meantime Thomas sent in a patch which gets rid of the FREEZE option
from cluster and makes it the default.

So now I'm wondering what the next move should be for this patch?

a. Are we waiting on Robert's patch to be commited before we can apply
Thomas's cluster with freeze as default?
b. Are we waiting on me reviewing one or both of the patches? Which one?

I think probably it sounds safer not to make freeze the default, but then
if we release 9.4 with CLUSTER FREEZE then in 9.5/10 decide it should be
the default then we then have a redundant syntax to support for ever and
ever.

Decision time?

Regards

David Rowley

> Greetings,
>
> Andres Freund
>
> --
> Andres Freund http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Albe Laurenz 2013-11-18 08:28:31 Re: writable FDWs / update targets confusion
Previous Message wangshuo 2013-11-18 08:14:16 Parse more than bind and execute when connect to database by jdbc