From: | Tim Perdue <tim(at)sourceforge(dot)net> |
---|---|
To: | |
Cc: | pgsql-hackers(at)hub(dot)org |
Subject: | Re: Fragged State in 7.0.2 |
Date: | 2000-09-06 15:14:42 |
Message-ID: | 39B65F62.D8E051F5@valinux.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
It doesn't suprise me that it doesn't work, but I am surprised to get
into a half-baked state if an abort does happen for some reason.
NOTICE: Caution: DROP TABLE cannot be rolled back, so don't abort now
Probably what should happen is it should error out if you try to do
things like this in a transaction, or autocommit for you no matter what.
Whatever it takes to not be in a half-baked state.
Tim
Tom Lane wrote:
>
> "Mike Mascari" <mascarm(at)mascari(dot)com> writes:
> > Rolling back DDL statements properly
> > in a MVCC transaction environment is very difficult, as
> > you can imagine. IIRC Oracle cheats, Informix and DEC Rdb
> > lock the DDL target until transaction commit, etc. If
> > the PostgreSQL team implements their stated goal in this
> > area, it will be far superior to its commercial counterparts.
>
> AFAIK we intend to keep the current behavior of exclusively
> locking any table you try to drop or modify. So it'll be
> pretty much like the Informix/RDB behavior.
>
> But yes, at the moment DROP or RENAME inside a transaction is
> pretty risky (and 7.0 tells you so, with an annoying NOTICE).
>
> regards, tom lane
--
Founder - PHPBuilder.com / Geocrawler.com
Lead Developer - SourceForge
VA Linux Systems
408-542-5723
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas SB | 2000-09-06 15:19:46 | AW: Yet another LIKE-indexing scheme |
Previous Message | Zeugswetter Andreas SB | 2000-09-06 15:02:01 | AW: AW: A fine point about OUTER JOIN semantics |