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

> Tom Lane <tgl@sss.pgh.pa.us> writes:
> Mike Mascari <mascarm@mascari.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? ;-)