On Mon, Jul 14, 2008 at 9:29 AM, Paul Libbrecht <paul(at)activemath(dot)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:
drop table yada;
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.
In response to
pgsql-admin by date
|Next:||From: Scott Marlowe||Date: 2008-07-14 18:10:46|
|Subject: Re: How to setup tablespace and table partitioning in a template?|
|Previous:||From: Carol Walter||Date: 2008-07-14 16:54:46|
|Subject: Re: accidental drop table recoverable? |