Re: pgsql: Integrate recovery.conf into postgresql.conf

David Steele <david@pgmasters.net>

From: David Steele <david@pgmasters.net>
To: Andres Freund <andres@anarazel.de>, Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Stephen Frost <sfrost@snowman.net>, Michael Paquier <michael@paquier.xyz>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Sergei Kornilov <sk@zsrv.org>, Postgres hackers <pgsql-hackers@postgresql.org>
Date: 2018-11-26T19:36:56Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Integrate recovery.conf into postgresql.conf

On 11/26/18 1:15 PM, Andres Freund wrote:
> On 2018-11-26 15:09:43 -0300, Alvaro Herrera wrote:
>> On 2018-Nov-26, Stephen Frost wrote:
>>
>>> I would think we'd have the different GUCs and then the check functions
>>> would only validate that they're valid inputs and then when we get to
>>> the point where we're starting to do recovery we check and make sure
>>> we've been given a sane overall configuration- which means that only
>>> *one* is set, and it matches the recovery target requested.
>>
>> I don't quite understand why it isn't sensible to specify more than one
>> and just stop recovery (or whatever) when at least one of them becomes
>> true.  Maybe I want to terminate just before commit of transaction
>> 12345, but no later than 2018-11-11 12:47 in any case.
> 
> +1

-1. At least for now.

Prior to this patch the last target specified in recovery.conf was the
one used, not a combination of them.

The committed patch did not propose to change that behavior as far as I
can see.  Since there is no way to determine the order of GUCs like
there was for options in recovery.conf, I think it makes sense to
restrict it to a single target type for now.  This is not exactly the
behavior we had before but I think it comes the closest.

Allowing multiple targets could be considered as a separate patch if
anyone is interested.

Regards,
-- 
-David
david@pgmasters.net