"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > 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.
Well then you're back in the same boat as using psql or any other subprocess. However I'm unconvinced that it cannot be done. Certainly the API separates pretty much each phase of the query process. You can issue queries and not look at the result set of the query immediately. What's unclear is what the driver is doing beneath the scenes. It may be reading the results sooner than the API makes it appear. There are also more places to potentially try to interleave actions than the API actually exposes. I'm not sure how important those additional points would be though since they are necessarily pretty small windows or else the API would expose them. So for example if you issue a query you can regain control before reading the actual results of the query. However you cannot regain control before the reading the message that indicates your query was at least received properly. In practice I'm not sure that matters since that one simple response would undoubtedly fit within the server's network buffers anyways so whether the client waits for it or not seems unlikely to have any effect on the server. There is also the problem of trying to have two processes reading results at the same time. Say you want to test that two concurrent sequential scans behave properly. libpq and therefore DBI since it's based on libpq can only read the entire result set. You can do things before you read the results, but once you ask for the results you don't get control back until the entire result set is ready. -- greg ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
