Re: Testing with concurrent sessions

On 7/01/2010 9:15 AM, Robert Haas wrote:
> On Wed, Jan 6, 2010 at 4:52 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov>  wrote:
>> "David E. Wheeler"<david@kineticode.com>  wrote:
>>
>>> Last I heard, Andrew was willing to require Test::More for
>>> testing, so that a Perl script could handle multiple psql
>>> connections (perhaps forked) and output test results based on
>>> them. But he wasn't as interested in requiring DBI and DBD::Pg,
>>> neither of which are in the Perl core and are more of a PITA to
>>> install (not huge, but the barrier might as well stay low).
>>
>> OK, I've gotten familiar with Perl as a programming language and
>> tinkered with Test::More.  What's not clear to me yet is what would
>> be considered good technique for launching several psql sessions
>> from that environment, interleaving commands to each of them, and
>> checking results from each of them as the test plan progresses.  Any
>> code snippets or URLs to help me understand that are welcome.  (It
>> seems clear enough with DBI, but I'm trying to avoid that per the
>> above.)
>
> Doing this without DBI is going to be ten times harder than doing it
> with DBI.  Are we really sure that's not a viable option?

At this point, I'm personally wondering if it's worth putting together a 
simple (ish) C program that reads a file describing command 
interleavings on n connections. It fires up one thread per connection 
required, then begins queuing commands up for the threads to execute in 
per-thread fifo queues. The input file may contain synchronization 
points where two or more explicitly specified threads (or just all 
threads) must finish all their queued work before they may be given more.

Yes, it requires wrangling low-level threading ( pthreads, or the 
practically equivalent for simple purposes but differently spelled win32 
threading ) so it's not going to be beautiful. But it'd permit a 
declarative form for tests and a single, probably fairly maintainable, 
test runner.

I reluctantly suspect that XML would be a good way to describe the tests 
- first a block declaring your connections and their conn strings, then 
a sequence of statements (each of which is associated with a named 
connection) and synchronization points. Though, come to think of it, a 
custom plaintext format would be pretty trivial too.

CONN conn1: dbname=regress, user=regress
CONN conn2: dbname=regress, user=regress
STMT conn1: SELECT blah blah;
STMT conn2: UPDATE blah blah;
SYNC conn1, conn2

etc. Or alternately one-file-per-connection (which would be handy if one 
connection has *lots* of commands and others only occasional ones) - the 
only trouble there being how to conveniently specify synchronization points.

Anyway: If Java were acceptable I'd put one together now - but somehow I 
don't think requiring Java would be popular if Perl is an issue ;-) My 
C/pthreads is more than a little bit rusty (ie: practially nonexistent) 
and mostly confined to exception-controlled C++ code with RAII for lock 
management. If C++ is OK, I can write and post a tool for evaluation, 
but if it must be plain C ... well, I'll avoid scarring you with the 
sight of what I'd produce.

I suspect that a custom tool for this job could actually be fairly 
simple. A lot simpler than a proper, clean and usable parallel psql, anyway.

--
Craig Ringer