Re: ALTER TABLE lock strength reduction patch is unsafe

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: ALTER TABLE lock strength reduction patch is unsafe
Дата
Msg-id 20140128172656.GK20898@momjian.us
обсуждение исходный текст
Ответ на Re: ALTER TABLE lock strength reduction patch is unsafe  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: ALTER TABLE lock strength reduction patch is unsafe  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
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 1FATAL:  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.  My guess is a lot of
people are going to assume the old postgresql.conf is not compatible and
are going to initdb and reload.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: A minor correction in comment in heaptuple.c
Следующее
От: Christian Convey
Дата:
Сообщение: Re: alternative back-end block formats