On 10/7/14, 2:11 AM, Feike Steenbergen wrote:
> 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.
Perhaps it wouldn't be too horrific to create some perl code that would figure out what all of those commands are, and
wecould 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
totest 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.
Wedon'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
testscould be structured in such a way that there's a subset of tests that just see if the command even executes, but
creatingthat is obviously a lot of work and with our current test framework probably a real pain to maintain.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com