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
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 |