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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
