Re: Proposal for changes to recovery.conf API - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: Proposal for changes to recovery.conf API
Date
Msg-id eb3f23a2-80e4-971c-7de4-ab825f1f3304@2ndquadrant.com
Whole thread Raw
In response to Re: Proposal for changes to recovery.conf API  (David Steele <david@pgmasters.net>)
Responses Re: Proposal for changes to recovery.conf API
List pgsql-hackers
On 06/09/16 13:52, David Steele wrote:
> On 9/6/16 4:56 AM, Petr Jelinek wrote:
>> On 06/09/16 07:18, Abhijit Menon-Sen wrote:
>>>
>>> Do we want something like this (easy to implement and document, perhaps
>>> not especially convenient to use):
>>>
>>>     recovery_target = 'xid'     # or 'time'/'name'/'lsn'/'immediate'
>>>     recovery_target_xid = xxx?  # the only setting we care about now
>>>     recovery_target_otherthings = parsed_but_ignored
>>>
>>> Or something like this (a bit harder to implement):
>>>
>>>     recovery_target = 'xid:xxx' # or 'time:xxx' etc.
>>>
>>
>> Personally, I never liked the fact that we have several config variables
>> for this and then the last one is chosen (even when it was in
>> recovery.conf). We support one recovery_target at a time so it would
>> make sense to have single config option for it IMHO.
>>
>> So +1 on the recovery_target = 'xid:xxx' idea.
>
> I would rather not combine the type and target into a single field - how
> about having two fields:
>
> recovery_target_type = 'xid|time|name|immediate'
> recovery_target = 'value'
>
> recovery_target would be ignored when recovery_target_type = 'immediate'.
>

That's also reasonable solution, I don't really have preference between 
those. My main point was to get rid of the 5 or so variables where only 
one will actually be used in the end.

--   Petr Jelinek                  http://www.2ndQuadrant.com/  PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: IF (NOT) EXISTS in psql-completion
Next
From: Amit Langote
Date:
Subject: Re: Declarative partitioning - another take