On Fri, 2011-01-14 at 17:18 -0500, Tom Lane wrote:
> Jaime Casanova <jaime@2ndquadrant.com> writes:
> > Here is a patch that implements "named restore points".
>
> > It allows DBAs to specify an exact point to which they can recover
> > but that point will have a name, so they have a better control of when
> > they want to stop recovery (ie: DBA's won't depend of remember
> > specific times, dates and such).
>
> > This adds a new function: pg_create_restore_point(text) (i'm not
> > wedded with the name so if someone wants to suggest something better,
> > that's fine with me), a new xlog record and a new recovery_target
> > parameter in recovery.conf
>
> This seems like it's a lot of mechanism for an awfully small use-case.
> How often are people actually going to have the foresight to know that
> "right now" is when they would want to restore to later? And is it
> really any easier to use a label for that than a timestamp? You're
> still going to need to keep track of which label means what.
I think its the other way around. In order to know what time to restore
to, you have to keep an external list of times when interesting things
happened. This gives you a way of putting that metadata into the log
stream so everything you need is in one place.
You can put a restore point in before or after any major activity, so
you can restore the database if that fails.
e.g. 'daily backup 2001/1/11', 'reference data update 2011/2/5',
'pg_upgrade', etc..
-- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services