Testing with concurrent sessions
in [PgSql]
|
From: Robert Haas on 6 Jan 2010 20:15 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? ....Robert -- 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: Andrew Dunstan on 6 Jan 2010 20:40 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? > > > 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) I'm persuadable on most things, but this one would take a bit of doing. A parallel psql seems to me a better way to go. We talked about that a while ago, but I don't recall what happened to it. cheers andrew -- 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: Robert Haas on 6 Jan 2010 20:49 On Wed, Jan 6, 2010 at 8:40 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote: >> 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. 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 wonder if it would make sense write a small wrapper program that uses libpq and dumps out the results in a format that is easy for Perl to parse. 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. > A parallel psql seems to me a better way to go. We talked about that a while > ago, but I don't recall what happened to it. That seems like a dead-end to me. It's hard for me to imagine it's ever going to be more than a toy. ....Robert -- 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: Tom Lane on 6 Jan 2010 21:26 Robert Haas <robertmhaas(a)gmail.com> writes: > 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 wonder if it would make sense write > a small wrapper program that uses libpq and dumps out the results in a > format that is easy for Perl to parse. > 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. We have not yet fully accepted the notion that you must have Perl to build (and, in fact, I am right now trying to verify that you don't). I don't think that requiring Perl to test is going to fly. >> A parallel psql seems to me a better way to go. We talked about that a while >> ago, but I don't recall what happened to it. > That seems like a dead-end to me. It's hard for me to imagine it's > ever going to be more than a toy. Well, the argument there is that it might be useful for actual use, not only testing. regards, tom lane -- 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: "Kevin Grittner" on 6 Jan 2010 21:31
Andrew Dunstan wrote: > Robert Haas wrote: >> 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) > > I'm persuadable on most things, but this one would take a bit of > doing. As far as I've been able to determine so far, to call psql in a relatively portable way would require something like this: http://perldoc.perl.org/perlfork.html Is that really better than DBI? Don't we need some way to routinely test multi-session issues? Other ideas? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |