On Mon, Jan 2, 2017 at 6:14 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 20 December 2016 at 15:11, Simon Riggs <si...@2ndquadrant.com> wrote: >> On 20 December 2016 at 15:03, Fujii Masao <masao.fu...@gmail.com> wrote: >> >>> API for crash recovery will never be changed. That is, crash recovery needs >>> neither recovery.trigger nor standby.trigger. When the server starts a crash >>> recovery without any trigger file, any recovery parameter settings in >>> postgresql.conf are ignored. Right? >> >> Yes. There are no conceptual changes, just the API. >> >> The goals are: visibility and reloading of recovery parameters, >> removal of special case code. > > OK, so here's the patch, plus doc cleanup patch.
Thanks for the patch! > 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? - if (PrimaryConnInfo == NULL && recoveryRestoreCommand == NULL) + if (SenderConnInfo == NULL && recoveryRestoreCommand == NULL) Seems "SenderConnInfo == NULL" should be changed to "SenderConnInfo[0] == '\0'". recoveryRestoreCommand, as well. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
