Re: [HACKERS] drop table inside transactions

From: jwieck(at)debis(dot)com (Jan Wieck)
To: sferac(at)proxy(dot)bazzanese(dot)com (Jose' Soares Da Silva)
Cc: meskes(at)topsystem(dot)de, pgsql-hackers(at)postgreSQL(dot)org, pgsq-bugs(at)postgreSQL(dot)org, sferac(at)bo(dot)nettuno(dot)it
Subject: Re: [HACKERS] drop table inside transactions
Date: 1998-04-30 09:44:56
Message-ID: m0yUpth-000BFRC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)debis(dot)com (Jan Wieck) #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Meskes 1998-04-30 11:28:28 TODO list
Previous Message Michael Meskes 1998-04-30 08:14:35 Re: [HACKERS] s_lock.h patch