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

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема AUTOCOMMIT currently doesn't handle non-transactional commands very well
Дата
Msg-id 87ac75yhr8.fsf@stark.xeocode.com
обсуждение исходный текст
Ответы Re: AUTOCOMMIT currently doesn't handle non-transactional commands very well  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Stefan Kaltenbrunner
Дата:
Сообщение: Re: CSStorm occurred again by postgreSQL8.2. (Re: poor
Следующее
От: Masanori ITOH
Дата:
Сообщение: Re: CSStorm occurred again by postgreSQL8.2. (Re: poor