I think what you're talking about here is physical delete vs. logical
delete. I may be blowing smoke here because I haven't been using
postgres that long. Other systems I've worked with mark a table or
file as deleted, but some operation like vacuum in this case is
required to actually delete the data and in all actuality it is still
really there till you overwrite it. When it's just marked as deleted
the system will overwrite other areas first but will use the deleted
file or tables space as a last resort. If you have the right fancy
software you can get it back. When it's physically deleted the
system will use the space as needed and overwrite as needed. You can
still get it back with the right fancy software, but it takes fancier
software and it's fraught with a lot more hazards.
Carol
On Jul 14, 2008, at 11:29 AM, Paul Libbrecht 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.
>
>> 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)
>
> this can be done easily.
> But the filesystem resurrect I am doubting of. I'll hunt.
>
> thanks!
>
> paul
>
>> 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.)
>
> sure!