Re: Proposal for changes to recovery.conf API

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal for changes to recovery.conf API
Date: 2017-01-11 10:36:09
Message-ID: CANP8+j+zcN1G_vMmoN3zx8_O+WqVZKys2AMHJxBtA_+8RZe0UA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11 January 2017 at 09:51, Fujii Masao <masao(dot)fujii(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2017-01-11 10:55:48 Re: postgres_fdw bug in 9.6
Previous Message Simon Riggs 2017-01-11 10:27:00 Re: Proposal for changes to recovery.conf API