Re: Recovering a deleted database problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Andy Shellam (Mailing Lists)" <andy(dot)shellam-lists(at)mailnetwork(dot)co(dot)uk>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Recovering a deleted database problem
Date: 2007-01-05 15:49:50
Message-ID: 16101.1168012190@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

"Andy Shellam (Mailing Lists)" <andy(dot)shellam-lists(at)mailnetwork(dot)co(dot)uk> writes:
> 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 :-) )

Well, I'd be a little worried about whether the base backup was
self-consistent, but if it was taken at a time where the DB was idle
then you can probably get away with this.

> 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?

AFAIK the only operations that have non-rollbackable side effects are
CREATE/DROP DATABASE and CREATE/DROP TABLESPACE. For any of these,
you'd end up with inconsistent state if you try to stop replay just
before the commit record.

regards, tom lane

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Jeanna Geier 2007-01-05 16:23:46 Can't See Data - Plz Help!
Previous Message Andy Shellam (Mailing Lists) 2007-01-05 15:26:28 Re: Recovering a deleted database problem