Paul Libbrecht <paul@activemath.org> 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
