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
|
Список | 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 по дате отправления: