Testing with concurrent sessions
in [PgSql]
|
From: "David E. Wheeler" on 3 Jan 2010 13:53 On Jan 1, 2010, at 6:01 PM, Kevin Grittner wrote: > It's very soon going to be critical that I be able to test particular > interleavings of statements in particular concurrent transaction sets > to be able to make meaningful progress on the serializable > transaction work. It would be wonderful if some of these scripts > could be integrated into the PostgreSQL 'make check' scripts, > although that's not an absolute requirement. I'm not really > concerned about performance tests for a while, just testing the > behavior of particular interleavings of statements in multiple > sessions. If psql isn't expected to support that soon, any > suggestions? Is pgTAP suited to this? We've discussed it a bit in the past with regard to testing replication and such. I think the consensus was, failing support for concurrent sessions in psql, to use a Perl script to control multiple psql sessions and perhaps use Test::More to do the testing. Although pgTAP might make sense, too, if the tests ought to run in the database. Best, David -- 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 4 Jan 2010 18:10 "David E. Wheeler" <david(a)kineticode.com> wrote: > I think the consensus was, failing support for concurrent sessions > in psql, to use a Perl script to control multiple psql sessions > and perhaps use Test::More to do the testing. Are there any examples of that? While I can hack my way through regular expressions when I need them, perl as a language is something I don't know at all; with an example I might be able to come up to speed quickly, though. > Although pgTAP might make sense, too, if the > tests ought to run in the database. I need to run statements against a database; I don't particularly need any special features of psql for this. Can anyone confirm that pgTAP can let you interleave specific statements against specific connections in a specific sequence? (The answer to that didn't leap out at me in a quick scan of the docs.) -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
From: Peter Eisentraut on 4 Jan 2010 18:29 On mån, 2010-01-04 at 17:10 -0600, Kevin Grittner wrote: > "David E. Wheeler" <david(a)kineticode.com> wrote: > > > I think the consensus was, failing support for concurrent sessions > > in psql, to use a Perl script to control multiple psql sessions > > and perhaps use Test::More to do the testing. > > Are there any examples of that? While I can hack my way through > regular expressions when I need them, perl as a language is > something I don't know at all; with an example I might be able to > come up to speed quickly, though. If you're not deep into Perl, perhaps ignore the Test::More comment for the moment and just use DBI to connect to several database sessions, execute your queries and check if the results are what you want. Once you have gotten somewhere with that, wrapping a test harness around it is something others will be able to help with. > > Although pgTAP might make sense, too, if the > > tests ought to run in the database. > > I need to run statements against a database; I don't particularly > need any special features of psql for this. Can anyone confirm that > pgTAP can let you interleave specific statements against specific > connections in a specific sequence? (The answer to that didn't leap > out at me in a quick scan of the docs.) pgTAP isn't really going to help you here, as it runs with *one* database session, and its main functionality is to format the result of SQL functions into TAP output, which is not very much like what you ought to be doing. -- 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: "David E. Wheeler" on 4 Jan 2010 18:40 On Jan 4, 2010, at 3:29 PM, Peter Eisentraut wrote: > If you're not deep into Perl, perhaps ignore the Test::More comment for > the moment and just use DBI to connect to several database sessions, > execute your queries and check if the results are what you want. Once > you have gotten somewhere with that, wrapping a test harness around it > is something others will be able to help with. 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). > pgTAP isn't really going to help you here, as it runs with *one* > database session, and its main functionality is to format the result of > SQL functions into TAP output, which is not very much like what you > ought to be doing. Right, exactly. Best, David -- 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: Markus Wanner on 5 Jan 2010 07:08
Hi, Kevin Grittner wrote: > It's very soon going to be critical that I be able to test particular > interleavings of statements in particular concurrent transaction sets > to be able to make meaningful progress on the serializable > transaction work. I've something in place for Postgres-R, as I also need to test concurrent transactions there. It's based on python/twisted and is able to start multiple Postgres instances (as required for testing replication) and query them concurrently (as you seem to need as well). It uses an asynchronous event loop (from twisted) and basically controls processes, issues queries and checks results and ordering constraints (e.g. transaction X must commit and return a result before transaction Y). I'm still under the impression that this testing framework needs cleanup. However, others already showed interest as well... Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |