On Tue, Aug 16, 2005 at 12:24:34AM -0400, Tom Lane wrote:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > 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 bit that I think is missing in DBI is "issue a command and don't
> wait for the result just yet". Without that, you cannot for instance
> stack up several waiters for the same lock, as you might wish to do to
> verify that they get released in the correct order once the original
> lock holder goes away. Or stack up some conflicting waiters and check
> to see if deadlock is detected when it should be ... or contrariwise,
> not signalled when it should not be. There's lots of stuff you can
> do that isn't exactly probing for race conditions, yet would be awfully
> nice to check for in a routine test suite.
>
> I might be wrong though, not being exactly a DBI guru ... can this
> sort of thing be done?
Even if it can't be done, would it be reasonable to spawn multiple perl
processes, each of which handles one database connection? I suspect it
wouldn't be too hard to write a daemon in perl that would sit between
the test code and a pile of DBI connections.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com 512-569-9461