Re: ALTER TABLE lock strength reduction patch is unsafe

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe
Date: 2014-01-28 14:55:15
Message-ID: 20140128145515.GC20898@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

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?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message salah jubeh 2014-01-28 14:58:36 Re: bison, flex and ./configure
Previous Message Heikki Linnakangas 2014-01-28 14:48:03 Re: bison, flex and ./configure