Testing with concurrent sessions
in [PgSql]
|
From: "Kevin Grittner" on 15 Jan 2010 15:32 Markus Wanner <markus(a)bluegap.ch> wrote: > So, the solution probably lies in adjusting the environment, > before starting psql. (Maybe even dropping all existing > environment variables for better control of the situation). Will > add that for dtester 0.1. Based on Andrew's suggestion, I changed line 276 to: args=['psql', '-A', '--pset=pager=off', I now get 5 of 6 tests succeeded (83.3%), processed in 18.5 seconds. I'm not clear on what you want to see from the run or whether it might be better sent off-list. Also, in looking closer at how you have the tests defined, it doesn't look to me like you're carefully interleaving specific sequences of statements on specific connections so much as opening multiple connections and then for each statement saying "run this on all connections." That's certainly a valid test to include, but I need the more controlled format, too. It does appear that that's pretty straightforward to code; you just haven't chosen to do so in the particular tests here, correct? -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: "Kevin Grittner" on 15 Jan 2010 15:53 "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> wrote: > Also, in looking closer at how you have the tests defined, it > doesn't look to me like you're carefully interleaving specific > sequences of statements on specific connections so much as opening > multiple connections and then for each statement saying "run this > on all connections." I take it back; you've got both. I do want to expand the tests quite a bit -- do I work them all into this same file, or how would I proceed? I think I'll need about 20 more tests, but I don't want to get in the way of your work on the framework which runs them. -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: "Kevin Grittner" on 15 Jan 2010 16:09 Markus Wanner <markus(a)bluegap.ch> wrote: > Please recheck with the StreamReporter and try to grep the lines > starting with "[psql0]", "[psql1]" and "[psql2]". Dtester simply > logs all and any output of all 3rd party processes started. For me, all psql output seems to be [psql0]; no [psql1] or [psql2]. Bug? -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: "Kevin Grittner" on 15 Jan 2010 17:39 Markus Wanner <markus(a)bluegap.ch> wrote: > Go try it, read the code and simply ask, if you get stuck. I'll > try to come up with some more documentation and such... I'm a little unclear about the differences between "uses", "depends", and "onlyAfter". Here's what they *sound* like they mean, to me; although I don't think the code isn't entirely consistent with this interpretation. "uses" means that the referenced task has complimentary setUp and tearDown methods, and the dependent task may only run after a successful invocation of the referenced task's setUp method, and the referenced task will wait for completion of all dependent tasks before invoking tearDown. "depends" means that the tearDown method of the referenced task doesn't undo the work of its setUp, at least for purposes of the dependent task. The dependent task can only start after successful completion of the referenced class's work (*just* setUp, or all the way to tearDown?), but the referenced task doesn't need to wait for the dependent task. "onlyAfter" means that the dependent task must wait for completion of the referenced task, but doesn't care whether or not the referenced class completed successfully. How close am I? -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: Markus Wanner on 16 Jan 2010 01:23
Hi, Kevin Grittner wrote: > I'm a little unclear about the differences between "uses", > "depends", and "onlyAfter". Here's what they *sound* like they > mean, to me; although I don't think the code isn't entirely > consistent with this interpretation. Wow, you are way ahead of me. I intended to write some documentation about that, but... I differentiate tests and test suites. Tests mainly have a run method, while test suites have setUp and tearDown ones. > "uses" means that the referenced task has complimentary setUp and > tearDown methods, and the dependent task may only run after a > successful invocation of the referenced task's setUp method, and the > referenced task will wait for completion of all dependent tasks > before invoking tearDown. Absolutely correct (may I just copy that para for documentation)? ;-) Two additional things: tests and test suites may have requirements (in the form of interfaces). The used test suites are passed to the dependent task and it may call the referenced tasks's methods, for example to get the database directory or to run a certain SQL command. Second, if the referenced task fails, any running dependent task is getting aborted as well. That might be obvious, though. > "depends" means that the tearDown method of the referenced task > doesn't undo the work of its setUp, at least for purposes of the > dependent task. The dependent task can only start after successful > completion of the referenced class's work (*just* setUp, or all the > way to tearDown?), but the referenced task doesn't need to wait for > the dependent task. Hm.. no, not quite. The fact that not all suites clean up after them has nothing to do with how they are referenced ("uses" or "depends"). So far, it's entirely up to the test suite. I dislike that, but it works. (I've been thinking about some separate resource allocation handling and what not, but..) The only difference between "depends" and "uses" is the requirements fulfilling. "uses" does that, while "depends" only adds the timing and functional dependencies, but doesn't pass the referenced task as an argument to the dependent task. > "onlyAfter" means that the dependent task must wait for completion > of the referenced task, but doesn't care whether or not the > referenced class completed successfully. That's how I think it *should* be. ATM "onlyAfter" requires successful completion of the dependent task. I'd like to change that to support "onlyAfter", "onlyAfterSuccessOf" and "onlyAfterFailureOf". Plus "onlyBefore" for convenience. This is all work in progress and I'm open to suggestions and requests. Thank you for thinking through all of this. I'm sure you understand now, why it's not a version 0.1, yet :-) Regards Markus -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |