Re: Testing of MVCC - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Testing of MVCC
Date
Msg-id 87u0hqwmqo.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Testing of MVCC  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Testing of MVCC  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> [ digs... ]  It looks like what I was remembering is
> http://search.cpan.org/~lbrocard/Test-Expect-0.29/lib/Test/Expect.pm
> which seems to leave all the interesting problems (like driving more
> than one program-under-test) to the user's own devices.  Sigh.

The goal here is to find race conditions in the server, right? There's no real
chance of any race condition errors in psql as far as I can see, perhaps in
the \commands but I don't think that's what you're worried about here.

So why bother with driving multiple invocations of psql under Expect. Just use
DBD::Pg to open as many connections as you want and issue whatever queries you
want. 

The driver program would be really simple. I'm not sure if you would specify
the series of queries with a perl data structure or define a text file format
that it would parse. Either seems pretty straightforward.

If you're worried about adding a dependency on DBD::Pg which would create a
circular dependency, well, it's just the test harness, it would just mean
someone would have to go build DBD::Pg before running the tests. (Personally
my inclination would be to break the cycle by including DBD::Pg in core but
that seems to be an uphill battle these days.)

-- 
greg



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] enable/disable trigger (Re: Fwd: Open items)
Next
From: Tom Lane
Date:
Subject: Re: Testing of MVCC