Re: Testing with concurrent sessions

Robert Haas wrote:
> It just seems crazy to me to try to test anything without proper
> language bindings. Opening a psql session and parsing the results
> seems extraordinarily painful.

I've written a Python based program that spawns a captive psql and talks
to it--twice for different people--that ultimately uses the same sort of
open3() spawning David mentioned is available via IPC::Open3. You can
throw together a prototype that works well enough for some purposes in a
couple of hours. I don't know that it would ever reach really robust
though.

The main problem with that whole approach is that you have to be
extremely careful in how you deal with the situation where the captive
program is spewing an unknown amount of information back at you. How do
you know when it's done? Easy for the child and its master to deadlock
if you're not careful. In the past I worked around that issue by just
waiting for the process to end and then returning everything it had
written until that time. I don't know that this would be flexible
enough for what's needed for concurrent testing, where people are
probably going to want more of a "send a command, get some lines back
again" approach that keeps the session open.

If I thought a captive psql would work well in this context I'd have
written a prototype already. I'm not sure if it's actually possible to
do this well enough to meet expectations. Parsing psql output is
completely viable for trivial purposes though, and if the requirements
were constrained enough it might work well enough for simple concurrent
testing. While both concurrent psql and the libpq shim you suggested
would take more work, I feel a bit more confident those would result in
something that really worked as expected on every platform when finished.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com