Re: Fragged State in 7.0.2

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

In response to

Browse pgsql-hackers by date

  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