From: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "Hannes Erven *EXTERN*" <hannes(at)erven(dot)at>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Revert TRUNCATE CASCADE? |
Date: | 2012-10-22 12:52:47 |
Message-ID: | D960CB61B694CF459DCFB4B0128514C2089A541F@exadv11.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hannes Erven wrote:
> today I ran into an issue I believed to be a FAQ, but fortunately it
> doesn't seem so as I could find any resources related to this... :-/
>
> A misguided click in PGADMIN executed a "TRUNCATE CASCADE" on a rather
> central table of my schema, which resulted in most important tables
> being emptied. Postgresql (9.0) was cleanly shut down immediately.
>
>
> Is there any chance to get the data back?
A dirty shutdown (-m immediate) would have been better.
Basically it is work for an expert to try and salvage data like this.
If (auto-)VACUUM has not run yet, maybe pg_resetxlog can do something
for you. But keep a copy of the original cluster before you start
messing around.
> There is a "pg_dumpall" backup from yesterday, and also pg_xlogs from
> well before the dumpall-file until the TRUNCATE command.
Unfortunately,
> there is no file system backup from the xlog timeframe and as far as I
> understood the documentation, a DUMP is no valid base for PITR. Time
to
> rework backup practices I guess...
I agree.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Angelico | 2012-10-22 13:17:13 | Plug-pull testing worked, diskchecker.pl failed |
Previous Message | Tom Lane | 2012-10-22 12:52:38 | Re: [ADMIN] Streaming Replication Server Crash |