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.


Fujii Masao

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to