Re: [HACKERS] drop table inside transactions - Mailing list pgsql-hackers

From jwieck@debis.com (Jan Wieck)
Subject Re: [HACKERS] drop table inside transactions
Date
Msg-id m0yUpth-000BFRC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to RE: [HACKERS] drop table inside transactions  ("Jose' Soares Da Silva" <sferac@proxy.bazzanese.com>)
Responses Re: [HACKERS] drop table inside transactions
List pgsql-hackers
>
> 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.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #

pgsql-hackers by date:

Previous
From: Tom Ivar Helbekkmo
Date:
Subject: Re: [HACKERS] Shared libs with version numbers.
Next
From: Michael Meskes
Date:
Subject: TODO list