Re: Recovery target 'immediate'

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?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +