Re: Add regression tests for autocommit-off mode for psql and fix some omissions

Jim Nasby-5 wrote
> On 10/7/14, 2:11 AM, Feike Steenbergen wrote:
>> On 7 October 2014 01:41, Jim Nasby<

> Jim.Nasby@

> > 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.
>
> Perhaps it wouldn't be too horrific to create some perl code that would
> figure out what all of those commands are, and we could then use that to
> generate the appropriate list for psql.
>
>> 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?
>
> Well, that is at least doable, but probably rather ugly. It would probably
> be less ugly if our test framework had a way to test for errors (ala
> pgTap).
>
> Where I was going with this is a full-on brute-force test: execute every
> possible command with autocommit turned off. We don't need to check that
> each command does what it's supposed to do, only that it can execute.
>
> Of course, the huge problem with that is knowing how to actually
> successfully run each command. :( Theoretically the tests could be
> structured in such a way that there's a subset of tests that just see if
> the command even executes, but creating that is obviously a lot of work
> and with our current test framework probably a real pain to maintain.

From the comments here the effort needed to prevent this particular
oversight seems excessive compared to the error it is trying to prevent - an
error that is fairly easily remedied in a minor release and which has an
easy work around.

That said can we just do:

"1) I don't know about a definitive way. I used grep to find all
statements calling PreventTransactionChain."

and save the results to an .out file with a comment somewhere that if there
is any change to the content of this file the corresponding command should
be manually tested in psql with autocommit=on. This seems to be what you
are saying but the psql check does not have to be automated...

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/Add-regression-tests-for-autocommit-off-mode-for-psql-and-fix-some-omissions-tp5821889p5823728.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.