On Thu, 30 Apr 1998, Jan Wieck wrote:
> >
> > On Fri, 17 Apr 1998, Meskes, Michael wrote:
> >
> > > Is this really a bug? I haven't seen any (commercial) system supporting
> > > this kind of transaction recovery. Once you drop a table the data is
> > > lost, no matter if you rollback or not.
> > >
> > > Michael
> > Maybe you are right Michael, but there's another point; the table wasn't
> > removed, it is still there, only data are cancelled.
> > It's more, like a DELETE FROM ... not a DROP TABLE...
> > and, if another user inserts data into this dropped table,
> > the table returns with all data.
> > (Refer to my first bug-report on this matter),
> > and more; some times ROLLBACK restores both data and table structure. ;-)
>
> Partially right. The tables data file was removed at DROP
> TABLE. On the ROLLBACK, the pg_class and pg_type entries got
> restored and the storage manager created a new (empty) data
> file on the SELECT command after the ROLLBACK.
>
> Maybe we could setup an internal list of files to be deleted
> on the next transaction commit, so the files remain intact
> after ROLLBACK.
Great!
Remember that we have the same problem with CREATE DATABASE
in case of ROLLBACK will be removed references from "pg_database"
but directory $PGDATA/databasename will not be removed.
Jose'
