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

From Simon Riggs
Subject Re: [HACKERS] Proposal for changes to recovery.conf API
Date
Msg-id CANP8+jKkc4-P2chPZBTZyoKwOFzsNdh4Ug1obiD06Kr8gte4Lw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Proposal for changes to recovery.conf API  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 3 January 2017 at 16:47, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Jan 3, 2017 at 11:21 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On 3 January 2017 at 15:50, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Sun, Jan 1, 2017 at 4:14 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>>> Trying to fit recovery targets into one parameter was really not
>>>> feasible, though I tried.
>>>
>>> What was the problem?
>>
>> There are 5 different parameters that affect the recovery target, 3 of
>> which are optional. That is much more complex than the two compulsory
>> parameters suggested when the proposal was made and in my view tips
>> the balance over the edge into pointlessness. Michael's suggestion for
>> 2 parameters works well for this case.
>
> I still think merging recovery_target_type and recovery_target_value
> into a single parameter could make sense, never mind the other three.
> But I don't really want to argue about it any more.

We all agree that reducing number parameters made sense and would
remove weird quirks of multiple settings. When we were discussing the
idea of replacing them with just 1 parameter, that idea made sense to
me after I'd thought about it, but it would actually be 4 parameters.
I couldn't see a way to wave the corner case parameters away.

After more detailed thought I don't see the point of reducing the
number of parameters from to 4, especially if that reduction comes
with increased complexity for one of the parameters. Better to just
have 5 as Michael suggested.

This patch replaces the previous 8 parameters with just 5.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Proposal for changes to recovery.conf API
Next
From: Jim Nasby
Date:
Subject: Re: [HACKERS] merging some features from plpgsql2 project