From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Recovery target 'immediate' |
Date: | 2013-04-26 16:50:20 |
Message-ID: | CABUevEwACxO+0YGt-raEKEUpMsG=OQBXOVOK196TTnmbtmN4oQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 26, 2013 at 6:43 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> 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?
I like that newer API suggestion better than what we have now - though
it can perhaps be improved even more. But I definitely don't think
it's worth breaking backwards compatibility for it. There are lots of
tools and scripts and whatnot out there that use the current API. I
think we need a bigger improvement than just a cleaner syntax to break
those.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2013-04-26 17:13:28 | Re: Recovery target 'immediate' |
Previous Message | Simon Riggs | 2013-04-26 16:43:35 | Re: Recovery target 'immediate' |