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.