Re: Add regression tests for autocommit-off mode for psql and fix some omissions - Mailing list pgsql-hackers
From | David G Johnston |
---|---|
Subject | Re: Add regression tests for autocommit-off mode for psql and fix some omissions |
Date | |
Msg-id | 1413838159917-5823728.post@n5.nabble.com Whole thread Raw |
In response to | Re: Add regression tests for autocommit-off mode for psql and fix some omissions (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Responses |
Re: Re: Add regression tests for autocommit-off mode for
psql and fix some omissions
|
List | pgsql-hackers |
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.
pgsql-hackers by date: