Re: Testing of MVCC

"Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:

> 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.

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