Re: accidental drop table recoverable? - Mailing list pgsql-admin

From Scott Marlowe
Subject Re: accidental drop table recoverable?
Date
Msg-id dcc563d10807141009y422ce863v38d45a40ab720962@mail.gmail.com
Whole thread Raw
In response to Re: accidental drop table recoverable?  (Paul Libbrecht <paul@activemath.org>)
List pgsql-admin
On Mon, Jul 14, 2008 at 9:29 AM, Paul Libbrecht <paul@activemath.org> wrote:
>
> Le 14-juil.-08 à 16:47, Tom Lane a écrit :
>
>> You can't really "rollback" a DROP TABLE --- that corresponds directly
>> to a filesystem remove() call, and no amount of fooling around with the
>> database state will undo that.
>
> That is dark.
> I read yesterday night that actually a vacuum was advised everyday since
> otherwise there was no actual deletion. So you are telling me that, however,
> drop-table does really go to deletion right away?
>
> I'm running 7.4.5 btw.

First off, if you're gonna run 7.4.x then you should REALLY be running
the latest 7.4 version, which is 7.4.21.  You are missing almost 4
years worth of updates, and there ARE dataloss bugs in 7.4.5 which
could bite you.  But that's not the core of your issue here.

When you delete tuples in a table, postgresql doesn't delete the
actual row, it just marks it as deleted / not visible anymore.  Same
goes for the corresponding entries in an index.

Dropping or truncating a table is something else.  Now, if you do:

begin;
drop table yada;
rollback;

you'll still have your table. Same thing goes for truncate.  But once
you commit such a transaction, the table is gone.  Keep in mind that
if you don't start a transaction explicitly, then each command you
type in is a transaction unto itself, and that means that a simple
drop table statement commits as soon as it finishes.

pgsql-admin by date:

Previous
From: Carol Walter
Date:
Subject: Re: accidental drop table recoverable?
Next
From: "Scott Marlowe"
Date:
Subject: Re: How to setup tablespace and table partitioning in a template?