Re: AUTOCOMMIT currently doesn't handle non-transactional commands very well - Mailing list pgsql-hackers

From Tom Lane
Subject Re: AUTOCOMMIT currently doesn't handle non-transactional commands very well
Date
Msg-id 14062.1153329124@sss.pgh.pa.us
Whole thread Raw
In response to Re: AUTOCOMMIT currently doesn't handle non-transactional commands very well  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> s/possible criticism/deal-breaker/ ... you can't possibly think that the
>> above would be acceptable.  It'd be worse than "won't be undoable"; it'd
>> probably corrupt your database.

> I'm not sure I understand why. Or are you just referring to the snapshot bugs
> in cluster?

The ROLLBACK would undo the catalog updates made by the command, but not
its non-transactional changes.  Possibly in some cases there would be
no resulting inconsistency, but in general it would leave inconsistent
state.  In most of our usages of PreventTransactionChain, the point is
that a rollback occuring after the command thinks it's completed would
be unsafe.

> I do have an alternative idea: Instead of having psql parse the SQL commands
> to try to guess which commands are non-transactional, have psql simply try the
> command, and check the error code.

I don't think it is really all that hard to have psql parse the commands
far enough to determine if they're transactional or not.  If you can't
tell by easy visual inspection which kind of command it is, then we've
misdesigned the command language and should change it: it'll be
confusing for people as well as programs.

In the case of the online-index-creation command, this may require
putting the critical keyword up front rather than burying it somewhere
in the command string, but I don't see a problem with that.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_regress breaks on msys
Next
From: Tom Lane
Date:
Subject: Re: pg_regress breaks on msys