Re: Recovery target 'immediate'

On 26 April 2013 17:25, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> wrote:
> On 26.04.2013 19:05, Simon Riggs wrote:
>>
>> On 26 April 2013 16:38, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
>>>
>>> On Fri, Apr 26, 2013 at 11:35 AM, Simon Riggs<simon(at)2ndquadrant(dot)com>
>>> wrote:
>>>>
>>>> Given that I was describing how we might implement Heikki's
>>>> suggestion, I find this comment confusing.
>>>>
>>>> Please explain.
>>>
>>>
>>> Heikki's suggestion is simply to have a mode that stops as soon as
>>> consistency is reached. The server already knows (from the backup
>>> label) what the consistency point is, so there's no need to add a
>>> restore point or anything else to the WAL stream to implement what
>>> he's talking about.
>>
>>
>> Using restore points just puts into use the facility that is already
>> best practice to use, put there for just this kind of situation.
>> I guess you could do recovery_target_name = '$consistent'
>>
>> Doing it the other way means you need to add a new kind of recovery
>> target to the API just for this.
>> recovery_target_immediate = on
>
>
> Sounds good to me.
>
> Actually, from a usability point of view I think would be nice to have just
> one setting, "recovery_target". It's already somewhat confusing to have
> recovery_target_xid, recovery_target_time, and recovery_target_name, which
> are mutually exclusive, and recovery_target_inclusive which is just a
> modifier for the others. Maybe something like:
>
> recovery_target = 'xid 1234'
> recovery_target = 'xid 1234 exclusive'
> recovery_target = '2013-04-22 12:33'
> recovery_target = '2013-04-22 12:33 exclusive'
> recovery_target = 'consistent'
> recovery_target = 'name: daily backup'

So now you want to change the whole existing API so it fits with your
one new requirement?

Sounds like flamebait to me, but -1, just in case you're serious.

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