Re: Testing with concurrent sessions
От | Marko Tiikkaja |
---|---|
Тема | Re: Testing with concurrent sessions |
Дата | |
Msg-id | 4B450B02.9070300@cs.helsinki.fi обсуждение исходный текст |
Ответ на | Re: Testing with concurrent sessions (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Testing with concurrent sessions
Re: Testing with concurrent sessions |
Список | pgsql-hackers |
On 2010-01-07 00:08 +0200, Peter Eisentraut wrote: > On ons, 2010-01-06 at 15:52 -0600, Kevin Grittner wrote: >> "David E. Wheeler"<david@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.) > > 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. I don't see how that would work, but I might have misunderstood what we're reaching for here. What I think would be most useful would be to interleave statements between transactions, not just randomly fire psql sessions and hope for race conditions. Regards, Marko Tiikkaja
В списке pgsql-hackers по дате отправления: