Re: [HACKERS] DROP TABLE inside transaction block - Mailing list pgsql-hackers

From Mike Mascari
Subject Re: [HACKERS] DROP TABLE inside transaction block
Date
Msg-id 19990929054551.28801.rocketmail@web2102.mail.yahoo.com
Whole thread Raw
In response to [HACKERS] DROP TABLE inside transaction block  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] DROP TABLE inside transaction block
Re: [HACKERS] DROP TABLE inside transaction block
List pgsql-hackers
--- Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > Seems like good comments on these items.  Anything
> for TODO list here?
>
> Actually, the current state of play is that I
> reduced the ERROR messages
> to NOTICEs in DROP TABLE and DROP INDEX ("NOTICE:
> DROP TABLE cannot be
> rolled back, so don't abort now"), since there
> seemed to be some
> unhappiness about making them hard errors.  I also
> put similar messages
> into RENAME TABLE and TRUNCATE TABLE.
>
> I have a personal TODO item to go and insert some
> more checks: per the
> discussions so far, CREATE/DROP DATABASE probably
> need similar messages,
> and I think we need to make VACUUM refuse to run
> inside a transaction
> block at all (since its internal commits will not do
> the intended thing
> if you do BEGIN; VACUUM).  Also on my list is to
> investigate these
> reports that CREATE VIEW and ALTER TABLE don't roll
> back cleanly ---
> there may be bugs lurking there.  If you want to add
> those to the
> public list, go ahead.
>
>             regards, tom lane

If my TRUNCATE TABLE patch was applied as submitted,
(I haven't downloaded a newer snapshot yet), then
it falls into category #2...same as VACUUM. It
commits the current transaction before truncating
the specified relation, then begins a new transaction.
Quite frankly, as Vadim pointed out in earlier posts,
PostgreSQL attempts to go "above and beyond" with
respect to rolling back transactions which contain
DDL statements.

>From the ORACLE 7 Server Manual:

Transaction

A transaction (or a logical unit of work) is a
sequence
of SQL statements that ORACLE treats as a single unit.
A transaction begins with the first executable SQL
statement after a COMMIT, ROLLBACK or connection to
ORACLE. A transaction ends with a COMMIT statement, a
ROLLBACK statement, or disconnection (intentional or
unintentional) from ORACLE. ORACLE issues an implicit
                            ^^^^^^^^^^^^^^^^^^^^^^^^^
COMMIT before and after any Data Definition Language
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
statement.
^^^^^^^^^

Anyways, so did the TRUNCATE TABLE patch.

For what its worth,

Mike Mascari
(mascarim@yahoo.com)

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: RI and PARSER (was: Re: [HACKERS] RI status report #1)
Next
From: "Hiroshi Inoue"
Date:
Subject: RE: [HACKERS] Recovery on incomplete write