Re: Testing with concurrent sessions - Mailing list pgsql-hackers

From Markus Wanner
Subject Re: Testing with concurrent sessions
Date
Msg-id 4B5161D4.7080907@bluegap.ch
Whole thread Raw
In response to Re: Testing with concurrent sessions  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: Testing with concurrent sessions  (Jan Urbański <wulczer@wulczer.org>)
List pgsql-hackers
Hi,

Kevin Grittner wrote:
> Based on Andrew's suggestion, I changed line 276 to:
>  
>             args=['psql', '-A', '--pset=pager=off',

That looks like a correct fix for psql, yes. Thanks for pointing that 
out Andrew.

Other processes might be confused by (or at least act differently with) 
a PAGER env variable, so that still needs to be cleared in general.

> I now get 5 of 6 tests succeeded (83.3%), processed in 18.5 seconds.

That's perfect. The one test that fails is expected to fail (another 
thing dtester doesn't support, yet). The serialization code you write 
should finally make that test pass ;-)
> I do want to expand the tests quite a bit -- do I work them all into> this same file, or how would I proceed?  I
thinkI'll need about 20> more tests, but I don't want to get in the way of your work on the> framework which runs
them.

Well, first of all, another piece of the missing manual: there are 
BaseTest and SyncTest classes. Those based on BaseTest runs within the 
event loop of the twisted framework, thus need to be written in the very 
same asynchronous fashion. Mostly calling async methods that return a 
Deferred object, on which you may addCallback() or addErrback(). See the 
fine twisted documentation, especially the part about "Low-Level 
Networking and Event Loop" here:

http://twistedmatrix.com/documents/current/core/howto/index.html

The SyncTest is based on BaseTest, but a new thread is created to run 
its run method, passing back its results to the main event loop when 
done. That allows you to call blocking methods without having to care 
about blocking the entire event loop.

However, it makes interacting between the two models a bit complicated. 
To call an async function from a SyncTest, you need to call the syncCall 
method. The separate thread then waits for some callback in the main 
event loop.

Both have their own set of caveats, IMO.

I'm not sure about how to organize the tests and ongoing development of 
the framework. I've already broken the Postgres-R tests with dtester-0.0.

Maybe we put up a git branch with the dtester patches included? So 
whenever I want to change the framework, I can check if and how it 
affects your tests.

Regards

Markus



pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Mammoth in Core?
Next
From: Heikki Linnakangas
Date:
Subject: Re: Streaming replication and non-blocking I/O