Re: AUTOCOMMIT currently doesn't handle non-transactional commands very well

Greg Stark <gsstark(at)mit(dot)edu> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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