Re: CLUSTER FREEZE - Mailing list pgsql-hackers

On 2013-11-18 11:39:44 -0500, Bruce Momjian wrote:
> On Mon, Nov 18, 2013 at 09:22:58PM +1300, David Rowley wrote:
> > So now I'm wondering what the next move should be for this patch?
> > 
> > a. Are we waiting on Robert's patch to be committed 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?
> 
> Yes, we probably should make a decision, unless Robert's idea can be
> implemented.  We have to balance the ease of debugging MVCC failures
> with the interface we give to the user community.

Imo that patch really doesn't need too much further work.

> From my perspective, I don't see how we can justify the addition of a
> FREEZE option to CLUSTER.  If we explain that you would always use
> FREEZE unless you want to preserve MVCC information for later debugging,
> users will reply with "Huh, why would I want that?"

I tend to agree that we should work towards not needing that option.

> Many MVCC failures are reproducible, so if we provide a C define that
> disables the freezing so MVCC information can be preserved, that might
> be good enough.  Developers could enable the macro, and the macro could
> be used in other places where MVCC information is lost.

> This will make some MVCC harder, and will perhaps allow some MVCC bugs
> to exist longer.

> I believe there are other cases where rows could be frozen but we have
> avoided it for MVCC debugging reasons.  Another idea would be the
> addition of a GUC that can disable optimistic freezing. This could be
> enabled by sites that suspect MVCC bugs.

I think that'd be an enormous failure. You don't usually need to look at
those because there's a bug in postgres' mvcc logic but somewhere
else (application, other postgres code). And looking at the mvcc
information helps you to narrow it down, so you have a chance of
actually finding a reproducible bug.
Besides, in many of the !rewrite cases it's far from clear in which
cases it's a benefit to freeze earlier.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services