On 10/7/14, 2:11 AM, Feike Steenbergen wrote:
On 7 October 2014 01:41, Jim Nasby<jim.na...@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 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.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to