Re: Testing with concurrent sessions

Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>

From: Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>, "David E. Wheeler" <david@kineticode.com>, pgsql-hackers@postgresql.org
Date: 2010-01-06T22:13:22Z
Lists: pgsql-hackers
On 2010-01-07 00:08 +0200, Peter Eisentraut wrote:
> On ons, 2010-01-06 at 15:52 -0600, Kevin Grittner 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.)
>
> Then I don't see much of a point in using Perl.  You might as well fire
> up a few psqls from a shell script.

I don't see how that would work, but I might have misunderstood what 
we're reaching for here.  What I think would be most useful would be to 
interleave statements between transactions, not just randomly fire psql 
sessions and hope for race conditions.


Regards,
Marko Tiikkaja