Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions

From: "Mike Mascari" <mascarm(at)mascari(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Lincoln Yeoh" <lylyeoh(at)mecomb(dot)com>, <pgsql-general(at)postgreSQL(dot)org>, "PostgreSQL Developers List" <hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
Date: 1999-11-26 19:48:20
Message-ID: 199911261949.OAA02196@corvette.mascari.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Mike Mascari <mascarm(at)mascari(dot)com> writes:
> > Well, I agree that it would be GREAT to be able to rollback DDL
> > statements. However, at the moment, failures during a transaction
while
> > DDL statements occur usually require direct intervention by the user
(in
> > the case of having to drop/recreate indexes) and often require the
services
> > of the DBA, if filesystem intervention is necessary (i.e., getting rid
of
> > partially dropped/created tables and their associated fileystem
> > files).
>
> And forced commit after the DDL statement completes will improve that
> how?

Because 99% of the instances of index and data corruption I've seen
have come from rolled-back DDL statements - usually because the on
disk representation no longer matches the system catalogue. A forced
commit on DDL changes against tables and indexes with access
exclusive locks will make that operation as close to "atomic" as
possible...

> As a user I'd be pretty unhappy if "SELECT ... INTO" suddenly became
> "COMMIT; SELECT; BEGIN". Not only would that mean that updates made
> by my transaction would become visible prematurely, but it might also
> mean that the SELECT retrieves results it should not (ie, results from
> xacts that were not committed when my xact started). Both of these
> things could make my application logic fail in hard-to-find, hard-to-
> reproduce-except-under-load ways.

What does ORACLE do here?

>
> So, although implicit commit might look like a convenient workaround at
> the level of Postgres itself, it'd be a horrible loss of reliability
> at the application level. I'd rather go with #1 (hard error) than
> risk introducing transactional bugs into applications that use Postgres.
>
>
> > Since ORACLE has 70% of the RDBMS market, it is the de facto standard
>
> Yes, and Windows is the de facto standard operating system. I don't use
> Windows, and I'm not willing to follow Oracle's lead when they make a
> bad decision...
>
> regards, tom lane

So I guess I should file away my other suggestion to use DCOM as
the object technology of choice instead of CORBA? ;-)

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Lamar Owen 1999-11-26 20:04:20 Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
Previous Message Tom Lane 1999-11-26 16:13:44 Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions

Browse pgsql-hackers by date

  From Date Subject
Next Message Lamar Owen 1999-11-26 20:04:20 Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
Previous Message Iradm 1999-11-26 19:23:25 Credit Kard 100$