On Tue, Aug 11, 2009 at 9:05 AM, Kevin Kempter
<kevink@consistentstate.com> wrote:
Hi all;
due to operator error at one of my client sites we're trying to restore a
deleted db.
We did a restore with a pgdump that went fine but the dump is 3weeks old. they
do have WAL segments and they claim that the WAL segments are exactly in line
with the needed transactions - from a timing perspective. However no base
backup with pg_start_backup() and pg_stop_backup() was ever run.
Is there any way to trick postgres into thinking that it needs to play fwd
these WAL's? Would it work to simply place them in a dir, create a
recovery.conf file pointing to that dir and restart the cluster?
Doubtful. I'm sure someone more in-the-know than I can give all the explanation needed but if my memory serves the problem is the transaction ID. You restored a database in an existing cluster or new cluster and those transactions locked up in those WAL files either A) have already occurred or B) have not yet occurred in that cluster.
That is my understanding of it. There may be more to it.
It'd be a neat service if such a restore were possible.
* Have all WAL logs from the creation of database X to it's current state
* Be able to apply those WAL logs to any cluster saying "restore only database X to time/transaction Y"
Greg
