Re: Recovery target 'immediate'

On Thu, May 2, 2013 at 7:40 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Fri, Apr 26, 2013 at 09:48:48AM -0400, Tom Lane wrote:
> > Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > > That said, maybe the easier choice for a *system* (such as v-thingy)
> > > would be to simply to the full backup using pg_basebackup -x (or
> > > similar), therefor not needing the log archive at all when restoring.
> > > Yes, it makes the base backup slightly larger, but also much
> > > simpler... As a bonus, your base backup would still work if you hosed
> > > your log archive.
> >
> > It doesn't appear to me that that resolves Heikki's complaint: if you
> > recover from such a backup, the state that you get is still rather vague
> > no? The system will replay to the end of whichever WAL file it last
> > copied.
> >
> > I think it'd be a great idea to ensure that pg_stop_backup creates a
> > well defined restore stop point that corresponds to some instant during
> > the execution of pg_stop_backup. Obviously, if other sessions are
> > changing the database state meanwhile, it's impossible to pin it down
> > more precisely than that; but I think this would satisfy the principle
> > of least astonishment, and it's not clear that what we have now does.
>
> Should I add this as a TODO item?
>
Definitely, it would make sense to note that somewhere.
Thanks!
--
Michael