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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
