On 28 January 2014 17:15, Bruce Momjian <br...@momjian.us> wrote: > 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.
(smiles) I have suggested parameters for many features, mostly in the early days of my developments before I saw the light if autotuning. But those were control parameters for tuning features. So yes, I have probably introduced more parameters than most, amongst the many things I've done. I'm guessing you don't recall how much trouble I went to in order to allow sync rep to have only 1 parameter, c'est la vie. What I'm discussing here is a compatibility parameter to allow new features to be disabled. This would be the third time in 10 years I suggested a parameter for that reason, i.e. one that the user would hardly ever wish to set. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers