Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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.



# 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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group