On Tue, Aug 16, 2005 at 12:24:34AM -0400, Tom Lane wrote: > Greg Stark <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Pervasive Software http://pervasive.com 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
