On Tue, Jan 28, 2014 at 04:36:39PM +0000, Simon Riggs wrote: > For me, reducing the strength of DDL locking is a major change in > RDBMS behaviour that could both delight and surprise our users. Maybe > a few actually depend upon the locking behaviour, maybe. After some > years of various people looking at this, I think we've got it right. > Experience tells me that while I think this is the outcome, we are > well advised to protect against the possibility that it is not correct > and that if we have corner case issues, it would be good to easily > disable this in the field. In the current case, a simple parameter > works very well to disable the feature; in other cases, not. > > Summary: This is an atypical case. I do not normally propose such > things - this is the third time in 10 years, IIRC.
Uh, in my memory, you are the person who is most likely to suggest a GUC of all our developers. > I have no problem removing the parameter if required to. In that case, > I would like to leave the parameter in until mid beta, to allow > greater certainty. In any case, I would wish to retain as a minimum an > extern bool variable allowing it to be turned off by C function if > desired. Anything changed to postgresql.conf during beta is going to require an initdb. Also, lots of backward-compatibility infrastructure, as you are suggesting above, add complexity to the system. I am basically against a GUC on this. We have far larger problems with 9.3 than backward compatibility, and limited resources. -- 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
