Re: accidental drop table recoverable?
От | Scott Marlowe |
---|---|
Тема | Re: accidental drop table recoverable? |
Дата | |
Msg-id | dcc563d10807141009y422ce863v38d45a40ab720962@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: accidental drop table recoverable? (Paul Libbrecht <paul@activemath.org>) |
Список | 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 по дате отправления: