Testing with concurrent sessions
in [PgSql]
|
From: Greg Smith on 7 Jan 2010 00:29 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(a)2ndQuadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 7 Jan 2010 00:30 On ons, 2010-01-06 at 14:10 -0800, David E. Wheeler wrote: > On Jan 6, 2010, at 2:08 PM, Peter Eisentraut wrote: > > > Then I don't see much of a point in using Perl. You might as well fire > > up a few psqls from a shell script > > If you're more comfortable with shell, then yes. Although then it won't run on Windows, will it? Well, I'm not saying that this is necessarily the better alternative. But you might have to compromise somewhere. Otherwise this project will take two years to complete and will be an unmaintainable mess (see pg_regress). -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 7 Jan 2010 00:38 On ons, 2010-01-06 at 20:49 -0500, Robert Haas wrote: > Another idea would be to make a set of Perl libpq bindings that is > simpler than DBD::Pg and don't go through DBI. If we put those in the > main source tree (perhaps as a contrib module) they would be available > wherever we need them. http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/perl5/?hideattic=0 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Craig Ringer on 7 Jan 2010 04:50 On 7/01/2010 9:15 AM, Robert Haas wrote: > On Wed, Jan 6, 2010 at 4:52 PM, Kevin Grittner > <Kevin.Grittner(a)wicourts.gov> wrote: >> "David E. Wheeler"<david(a)kineticode.com> wrote: >> >>> Last I heard, Andrew was willing to require Test::More for >>> testing, so that a Perl script could handle multiple psql >>> connections (perhaps forked) and output test results based on >>> them. But he wasn't as interested in requiring DBI and DBD::Pg, >>> neither of which are in the Perl core and are more of a PITA to >>> install (not huge, but the barrier might as well stay low). >> >> OK, I've gotten familiar with Perl as a programming language and >> tinkered with Test::More. What's not clear to me yet is what would >> be considered good technique for launching several psql sessions >> from that environment, interleaving commands to each of them, and >> checking results from each of them as the test plan progresses. Any >> code snippets or URLs to help me understand that are welcome. (It >> seems clear enough with DBI, but I'm trying to avoid that per the >> above.) > > Doing this without DBI is going to be ten times harder than doing it > with DBI. Are we really sure that's not a viable option? At this point, I'm personally wondering if it's worth putting together a simple (ish) C program that reads a file describing command interleavings on n connections. It fires up one thread per connection required, then begins queuing commands up for the threads to execute in per-thread fifo queues. The input file may contain synchronization points where two or more explicitly specified threads (or just all threads) must finish all their queued work before they may be given more. Yes, it requires wrangling low-level threading ( pthreads, or the practically equivalent for simple purposes but differently spelled win32 threading ) so it's not going to be beautiful. But it'd permit a declarative form for tests and a single, probably fairly maintainable, test runner. I reluctantly suspect that XML would be a good way to describe the tests - first a block declaring your connections and their conn strings, then a sequence of statements (each of which is associated with a named connection) and synchronization points. Though, come to think of it, a custom plaintext format would be pretty trivial too. CONN conn1: dbname=regress, user=regress CONN conn2: dbname=regress, user=regress STMT conn1: SELECT blah blah; STMT conn2: UPDATE blah blah; SYNC conn1, conn2 etc. Or alternately one-file-per-connection (which would be handy if one connection has *lots* of commands and others only occasional ones) - the only trouble there being how to conveniently specify synchronization points. Anyway: If Java were acceptable I'd put one together now - but somehow I don't think requiring Java would be popular if Perl is an issue ;-) My C/pthreads is more than a little bit rusty (ie: practially nonexistent) and mostly confined to exception-controlled C++ code with RAII for lock management. If C++ is OK, I can write and post a tool for evaluation, but if it must be plain C ... well, I'll avoid scarring you with the sight of what I'd produce. I suspect that a custom tool for this job could actually be fairly simple. A lot simpler than a proper, clean and usable parallel psql, anyway. -- Craig Ringer -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Greg Sabino Mullane" on 7 Jan 2010 10:17
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >> Doing this without DBI is going to be ten times harder than doing it >> with DBI. Are we really sure that's not a viable option? > In the buildfarm? Yes, I think so. The philosophy of the buildfarm is > that it should do what you would do yourself by hand. > > And adding DBI as a requirement for running a buildfarm member would be > a significant extra barrier to entry, ISTM. (I am very fond of DBI, and > use it frequently, BTW) What about something less than a requirement then? If you have it great, you can run these extra tests. If you don't have it, no harm, no foul. We could even bundle DBI and DBD::Pg to ensure that the minimum versions are there. All the prerequisites should be in place for 99% of the machines: a C compiler and Perl are the biggies, and I can't see any buildfarm members running without those. :) - -- Greg Sabino Mullane greg(a)turnstep.com PGP Key: 0x14964AC8 201001071014 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAktF+ucACgkQvJuQZxSWSsjYOgCglyLIyGCr60og+iQSnyRgkowd +lYAnRDjPe/XxC7gb9OBPdpZlqU0wncK =kPIR -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |