Paul Libbrecht <paul@xxxxxxxxxxxxxx> writes: > right now we experienced the loss of backups (due to wrong > communication) and a list of accidental drop table statements (due to > wrong database choice). Ouch. > We sure have clues how to avoid that in the future but right now we do > not seem to find the solution to actually rollback this accidental > drop table. 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. If you have filesystem tools that will resurrect the deleted files for you, you could probably put them back into the database. My inclination would be not to try to "roll back" anything, but create new tables with the identical column sets to the old ones (but no indexes) and then rename the recovered files into place to match the new tables' relfilenode values. After which, a dump and reload would be prudent to make sure everything's really kosher. (Actually, copying the data into newly created tables should be enough for that.) regards, tom lane
