Re: Recovering a deleted database problem

Thanks for the info Tom, too much data will have been entered into the
other databases in the cluster by now so I cannot give it another shot
on that server, plus all of yesterday's WAL logs will have been purged
by now by the daily backup routine.

Is it enough to simply have re-copied in the base/xxx directory from the
base backup, after the PITR recovery had completed (obviously any
changes made to that database since the base backup won't have been
restored but thankfully it's backed up nightly and doesn't change too
often :-) ) All CRUD operations seem to be working on that database OK
and the app that (I now know) uses it hasn't complained.

What I'll probably do is try to simulate the same process again on a
different machine to get myself a bit more familiar. Is there any other
situations you can think of where this may also be relevant, or is it
just when dropping a complete database?

Many thanks,

Andy.

Tom Lane wrote:
> "Andy Shellam (Mailing Lists)" <andy(dot)shellam-lists(at)mailnetwork(dot)co(dot)uk> writes:
>
>> (Note, after writing this, I tried restoring to a minute earlier (ie.
>> 18:57:40) and still have the same problem.
>>
>
> The PITR recovery process in effect rolls forward until it finds
> a transaction-commit record >= the specified time. Now for normal
> database operations, stopping just short of the commit of the
> transaction is enough to ensure that the transaction has no effect.
> But for the XLOG_DBASE_DROP record, not so --- replaying that means
> "rm -rf base/whatever". So you've got to make sure the replay stops
> before it reaches that record, and that means you need a stop time
> <= the commit time of some *prior* transaction. I suppose this was
> a slow time of day and you didn't have any other commits in the prior
> minute :-( ... so take another look in the log and see what was the
> last commit before that, and use that time.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
> !DSPAM:37,459e6a32137101648020742!
>
>
>

--
Andy Shellam
NetServe Support Team

the Mail Network
"an alternative in a standardised world"