On Fri, Apr 26, 2013 at 6:43 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 26 April 2013 17:25, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: >> On 26.04.2013 19:05, Simon Riggs wrote: >>> >>> On 26 April 2013 16:38, Robert Haas<robertmh...@gmail.com> wrote: >>>> >>>> On Fri, Apr 26, 2013 at 11:35 AM, Simon Riggs<si...@2ndquadrant.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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
