Re: Proposal for changes to recovery.conf API

From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
To: David Steele <david(at)pgmasters(dot)net>, pgsql-hackers(at)postgresql(dot)org, Abhijit Menon-Sen <abhijit(dot)menon-sen(at)2ndquadrant(dot)com>
Subject: Re: Proposal for changes to recovery.conf API
Date: 2016-09-06 13:01:44
Message-ID: eb3f23a2-80e4-971c-7de4-ab825f1f3304@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2016-09-06 13:04:09 Re: Declarative partitioning - another take
Previous Message Kyotaro HORIGUCHI 2016-09-06 13:00:26 Re: IF (NOT) EXISTS in psql-completion