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

From: Gregory Stark <gsstark(at)mit(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: AUTOCOMMIT currently doesn't handle non-transactional commands very well
Date: 2006-07-19 11:08:11
Message-ID: 87ac75yhr8.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 is not already in a transaction block and
is not itself a BEGIN or other transaction-control command, nor a
command that 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masanori ITOH 2006-07-19 11:11:28 Re: CSStorm occurred again by postgreSQL8.2. (Re: poor
Previous Message Stefan Kaltenbrunner 2006-07-19 10:53:53 Re: CSStorm occurred again by postgreSQL8.2. (Re: poor