Skip site navigation (1) Skip section navigation (2)

Re: Testing with concurrent sessions

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Michael Tan <mtanhl(at)gmail(dot)com>, david(at)kineticode(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Testing with concurrent sessions
Date: 2010-01-16 06:51:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

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 think I'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:

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.



In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-01-16 07:49:42
Subject: Re: Streaming replication and non-blocking I/O
Previous:From: Markus WannerDate: 2010-01-16 06:23:34
Subject: Re: Testing with concurrent sessions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group