Re: ALTER TABLE lock strength reduction patch is unsafe

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, 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 17:30:47
Message-ID: 52E7E947.7070102@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01/28/2014 07:26 PM, Bruce Momjian wrote:
> On Tue, Jan 28, 2014 at 07:21:50PM +0200, Heikki Linnakangas wrote:
>>>> 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.
>
> Uh, if we ship beta1 with a GUC in postgresql.conf, and then we remove
> support for the GUC in beta2, anyone starting a server initdb-ed with
> beta1 is going to get an error and the server is not going to start:
>
> LOG: unrecognized configuration parameter "xxx" in file "/u/pgsql/data/postgresql.conf" line 1
> FATAL: configuration file "/u/pgsql/data/postgresql.conf" contains errors
>
> so, yeah, it isn't going to require an initdb, but it is going to
> require everyone to edit their postgresql.conf.

Only if you uncommented the value in the first place.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-01-28 17:32:35 Re: KNN-GiST with recheck
Previous Message Andres Freund 2014-01-28 17:30:40 Re: A minor correction in comment in heaptuple.c