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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +