<p dir="ltr"><br /> On Apr 26, 2013 4:38 PM, "Robert Haas" <<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>>wrote:<br /> ><br /> > On Fri, Apr 26, 2013 at
10:05AM, Simon Riggs <<a href="mailto:simon@2ndquadrant.com">simon@2ndquadrant.com</a>> wrote:<br /> > >
Restorepoints are definitely the way to go here, this is what they<br /> > > were created for. Stopping at a
labelledlocation has a defined<br /> > > meaning for the user, which is much better than just "stop anywhere<br
/>> > convenient", which I found so frightening.<br /> > ><br /> > > It should be straightforward to
createa restore point with the same<br /> > > name as used in pg_start_backup('text');<br /> > ><br /> >
>pg_basebackup backups would need to use a unique key, which is harder<br /> > > to achieve. If we write a WAL
recordat backup start that would make<br /> > > the starting LSN unique, so we could then use that for the
restore<br/> > > point name for that backup.<br /> > ><br /> > > If people want anything else they
canrequest an additional restore<br /> > > point at the end of the backup.<br /> ><br /> > I personally
findthis to be considerably more error-prone than<br /> > Heikki's suggestion. On the occasions when I have had the
dubious<br/> > pleasure of trying to do PITR recovery, it's quite easy to supply a<br /> > recovery target that
neveractually gets matched - and then you<br /> > accidentally recover all the way to the end of WAL. This is not
fun.<br/> > Having a bulletproof way to say "recover until you reach consistency<br /> > and then stop" is a much
nicerAPI. I don't think "stop as soon as<br /> > possible" is at all the same thing as "stop anywhere
convenient".<br/> ><p dir="ltr">Thinking some more about it, this could also be useful together with pausing at the
recoverytarget to get a quick look at the state of things before recovering further. I assume that would work as well,
sinceit would be "a recovery target like the others".. <p dir="ltr">/Magnus