Re: [HACKERS] Proposal for changes to recovery.conf API
От | Simon Riggs |
---|---|
Тема | Re: [HACKERS] Proposal for changes to recovery.conf API |
Дата | |
Msg-id | CANP8+j+zcN1G_vMmoN3zx8_O+WqVZKys2AMHJxBtA_+8RZe0UA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Proposal for changes to recovery.conf API (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: [HACKERS] Proposal for changes to recovery.conf API
Re: [HACKERS] Proposal for changes to recovery.conf API |
Список | pgsql-hackers |
On 11 January 2017 at 09:51, Fujii Masao <masao.fujii@gmail.com> wrote: >> 5. recovery.conf parameters are all moved to postgresql.conf, with these changes > > In current design of the patch, when recovery parameters are misconfigured > (e.g., set recovery_target_timeline to invalid timeline id) and > the configuration file is reloaded, the startup process emits FATAL error and > the server goes down. I don't think this is fine. Basically even > misconfiguration of the parameters should not cause the server crash. > If invalid settings are supplied, I think that we just should warn them > and ignore those new settings, like current other GUC is. Thought? Thanks for your comments. The specification of the recovery target parameters should be different, IMHO. If the user is performing a recovery and the target of the recovery is incorrectly specified then it is clear that the recovery cannot continue with an imprecisely specified target. So in my understanding we would need to either 1) issue a WARNING and pause recovery 2) issue an ERROR (which becomes FATAL in Startup process) and exit recovery My view would be 2) is the most useful, though I am willing to hear other points and/or go with majority view -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: