On Tue, 2007-01-09 at 08:37 -0600, Ben K. wrote:
> On Mon, 8 Jan 2007, Simon Riggs wrote:
>
> > There is a log analysis tool on pgfoundry that does something similar.
>
> > You can already stop recovery at a certain point. So there's nothing to
> > stop you doing a recovery on a development machine up to a certain
> > point, then dumping the deleted data using pg_dump and re-loading it
> > into the live server. Then erasing the dev recovered database.
>
> What I looked for was something like "undo" to a state which includes some
> changes from the last backup.
>
> What is the best practice in the following case? I'd appreciate to know
> how this kind of situation is handled in general.
>
> - We keep daily backups.
> - In the middle of the day we find there are problems in some of the
> recent delete or update operations
> - But we want to keep hours of other insert, delete or updates that preceded the problematic
> delete/update
>
> We can do hourly backup of the production server to minimize the recovery
> efforts, but it seems costly considering this situation is not frequent.
>
> Since the logs contains what's been done, it appears it should be possible
> to go back in time - as PITR does - by relying only on sql dump and the
> statements in the log, with a controlled scope.
PITR doesn't go back in time. It only supports roll-forward from a prior
base backup using the logs, stopping at a predefined time/xid/endoflogs.
Going backwards using the logs is mostly impossible because the log
records don't hold enough info to un-erase things.
It is theoretically possible to enhance the server to be able to rewind
the data in a table by uncommitting transactional changes, but again you
can't put back data that has been emoved by VACUUM. That feature would
be similar to flashback, but its more complex then it sounds at first
hearing. I wouldn't hold your breath while waiting for that.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
