On Mon, Jul 14, 2008 at 9:29 AM, Paul Libbrecht <paul@xxxxxxxxxxxxxx> 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.
