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

From Philip Warner
Subject Re: [HACKERS] DROP TABLE inside a transaction block
Date
Msg-id 3.0.5.32.20000308192619.01fbb240@mail.rhyme.com.au
Whole thread Raw
In response to Re: [HACKERS] DROP TABLE inside a transaction block  (Mike Mascari <mascarm@mascari.com>)
List pgsql-hackers
>but it does, because the "effect" of the drop table is an action
>that is seen by all sessions, as though it were "committed". So I
>am now wondering, are there any
>Multi-Versioning/Multi-Generational RDBMS that support
>ROLLBACK-able DDL statements in transactions...
>

Dec/Rdb for one. They do, however, make their lives easier by 'locking the
metadata' when a user does a select. This means the 'drop table' would hang
until the first user commits. I think it even hangs until the first user
exits - basically if they have referenced tha table, you can't touch it
until they exit. But they do allow rollback on all DDL statements.

They do not allow rollback on 'managment' functions like moving storage
areas (where one or more tables are stored) across disks, doing vacuum-like
functions etc.


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: +61-03-5367 7422            |                 _________  \
Fax: +61-03-5367 7430            |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] DROP TABLE inside a transaction block