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

From Gregory Stark
Subject AUTOCOMMIT currently doesn't handle non-transactional commands very well
Date
Msg-id 87ac75yhr8.fsf@stark.xeocode.com
Whole thread Raw
Responses Re: AUTOCOMMIT currently doesn't handle non-transactional commands very well  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
The psql manual says this:

AUTOCOMMIT     ... The autocommit-off mode works by issuing an implicit BEGIN for you,     just before any command that
isnot already in a transaction block and     is not itself a BEGIN or other transaction-control command, nor a
commandthat cannot be executed inside a transaction block (such as     VACUUM).
 

Unfortunately that's not precisely true. In fact psql cannot know whether the
command can be executed within a transaction block since some commands, like
CLUSTER and now CREATE INDEX, sometimes can and sometimes can't.

The basic problem is that really we want to be able to run these commands even
if a transaction has been started as long as nothing else has been done in
that transaction (including the savepoint that psql also does automatically).
Would it work to just check whether the serializable snapshot has been set?
That would be simpler than the current logic.

One possible criticism is that a user that manually does BEGIN; CLUSTER
DATABASE; ROLLBACK; won't be warned that the cluster will not be undoable. It
seems to me that perhaps we want to somehow distinguish between manually
invoked BEGIN where we would want to notify the user if they're trying to run
something that will be committed automatically and implicit BEGIN which starts
a new transaction but only the next time a transactional command is run.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: CSStorm occurred again by postgreSQL8.2. (Re: poor
Next
From: Masanori ITOH
Date:
Subject: Re: CSStorm occurred again by postgreSQL8.2. (Re: poor