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@2ndQuadrant.com  www.2ndQuadrant.com