On Fri, Apr 26, 2013 at 09:48:48AM -0400, Tom Lane wrote: > Magnus Hagander <mag...@hagander.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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
