Re: ALTER TABLE lock strength reduction patch is unsafe - Mailing list pgsql-hackers

On 28 January 2014 14:55, Bruce Momjian <bruce@momjian.us> wrote:
> On Mon, Jan 27, 2014 at 08:57:26PM +0000, Simon Riggs wrote:
>> We get the new behaviour by default and I expect we'll be very happy with it.
>>
>> A second thought is that if we have problems of some kind in the field
>> as a result of the new lock modes then we will be able to turn them
>> off. I'm happy to fix any problems that occur, but that doesn't mean
>> there won't be any. If everybody is confident that we've foreseen
>> every bug, then no problem, lets remove it. I recall being asked to
>> add hot_standby = on | off for similar reasons.
>
> Addressing a larger issue, I have no problem with systematically adding
> GUCs to turn off features we add in each major release if we can also
> systematically remove those GUCs in the next major release.

Agreed. I propose 2 releases since the time between release of 9.4 and
the feature freeze of 9.5 is only 4 months, not usually enough for
subtle bugs to be discovered.

> This would require putting all these settings in the compatibility
> section of postgresql.conf.

Agreed, that is where I have added the parameter.

> However, I don't think it makes sense to do this in a one-off manner.
> It is also possible that there are enough cases where we _can't_ turn
> the feature off with a GUC that this would be unworkable.
>
> So, if we can't do it systematically, that means we will have enough
> breakage cases that we just need to rush out new versions to fix major
> breakage and one-off GUCs just don't buy us much, and add confusion.
>
> Does that make sense?

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.

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.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services