On 01/28/2014 07:15 PM, Bruce Momjian 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.
I don't understand why anyone would want to turn this feature off, ie.
require stronger locks than necessary for a DDL change.
If we're not confident that the patch is correct, then it should not be
applied. If we are confident enough to commit it, and a bug crops up
later, we'll fix the bug as usual.
A user savvy enough to fiddle with such a GUC can also do their DDL with:
BEGIN;
LOCK TABLE <table>
<DDL>
COMMIT;
>> 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.
Huh? Surely not.
- Heikki