Re: CLUSTER FREEZE

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.

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?" MVCC debugging is
just too rare an event for them to understand its usefulness.

If we do add FREEZE, all we would be doing is delaying the time when all
CLUSTER operations will use FREEZE, and hence debugging will be just as
difficult. My point is that will full knowledge, everyone would use
FREEZE unless they expect MVCC bugs, which is going to be an almost zero
population.

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.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +