Apologies for the previous message, I didn't send the full version.
On 6 October 2014 16:01, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> What class of bug would that prevent exactly?
ERROR: [...] cannot run inside a transaction block
when:
- running psql in AUTOCOMMIT off
- not having started a transaction yet
Currently some statements (ALTER TYPE name ADD VALUE, DROP INDEX CONCURRENTLY)
can only be run in psql when enabling autocommit
(which I consider a bug - either in the code, or in the documentation),
whilst many others (VACUUM, CREATE DATABASE) can be run in AUTOCOMMIT
off because
they will not implicitly create a transaction in psql.
> It seems to me like
> something that would normally get forgotten when we add any new
> such statement.
I think that is probably true; it has already been forgotten to be added
to psql for a few commands.
Perhaps I am the only one using autocommit-off mode and we shouldn't put effort
into fixing this?
For me the reason to add some tests was to make sure that the current behaviour
will not change in future versions; the function command_no_begin might be added
to, modified, or rewritten.
On 7 October 2014 01:41, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> The options I see...
>
> 1) If there's a definitive way to tell from backend source code what
> commands disallow transactions then we can just use that information to
> generate the list of commands psql shouldn't do that with.
>
> 2) Always run the regression test with auto-commit turned off.
>
> 3) Run the regression in both modes (presumably only on the build farm due
> to how long it would take).
1) I don't know about a definitive way. I used grep to find all statements calling PreventTransactionChain.
2) - I expect most people use autocommit-on; so only running it in autocommit-off would not test the majority of
users. - autocommit-off also obliges you to explicitly rollback transactions after
errors occur; this would probably mean a rewrite of some tests?
kind regards,
Feike Steenbergen
