From: | Mike Mascari <mascarim(at)yahoo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] DROP TABLE inside transaction block |
Date: | 1999-09-29 05:45:51 |
Message-ID: | 19990929054551.28801.rocketmail@web2102.mail.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
--- Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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(at)yahoo(dot)com)
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 1999-09-29 07:20:14 | RE: [HACKERS] Recovery on incomplete write |
Previous Message | Thomas Lockhart | 1999-09-29 04:41:26 | Re: RI and PARSER (was: Re: [HACKERS] RI status report #1) |