Re: Recovery target 'immediate'

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/

In response to

Responses

Browse pgsql-hackers by date

  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'