Testing with concurrent sessions
in [PgSql]
|
From: Marko Tiikkaja on 7 Jan 2010 11:13 On 2010-01-07 11:50 +0200, Craig Ringer wrote: > On 7/01/2010 9:15 AM, 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? > > 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. > 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. I had a similar syntax in mind, but instead of using threads, just execute the file in order using asynchronous connections. Regards, Marko Tiikkaja -- 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: Marko Tiikkaja on 7 Jan 2010 11:27 On 2010-01-07 18:13 +0200, Marko Tiikkaja wrote: > I had a similar syntax in mind, but instead of using threads, just > execute the file in order using asynchronous connections. I completely failed to make the point here which was to somehow mark which statements will (or, should) block. So here we go: A=> BEGIN; B=> BEGIN; A=> UPDATE foo ..; &B=> UPDATE foo ..; -- this will block A=> COMMIT; B=> SELECT * FROM foo; B=> COMMIT; [expected output here] Regards, Marko Tiikkaja -- 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 7 Jan 2010 11:32 On Jan 6, 2010, at 6:26 PM, Tom Lane wrote: > 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. I believe that the build farm already requires Perl, regardless of whether the PostgreSQL build itself requires it. 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: Tom Lane on 7 Jan 2010 11:38 "Greg Sabino Mullane" <greg(a)turnstep.com> writes: > We could even bundle DBI and DBD::Pg to ensure that the minimum versions > are there. As a packager, my reaction to that is "over my dead body". We have enough trouble keeping our own software up to date, and pretty much every external component that we've started to bundle has been a disaster from a maintenance standpoint. (Examples: the zic database is constant work and yet almost never up to date; the snowball stemmer never gets updated.) 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: Andrew Dunstan on 7 Jan 2010 11:46
David E. Wheeler wrote: > On Jan 6, 2010, at 6:26 PM, Tom Lane wrote: > > >> 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. >> > > I believe that the build farm already requires Perl, regardless of whether the PostgreSQL build itself requires it. > > > Unless I am mistaken, Perl is required in any case to build from CVS, although not from a tarball. DBI/DBD::pg is quite another issue, however. I have been deliberately very conservative about what modules to require for the buildfarm, and we have similarly (and I think wisely) been conservative about what modules to require for Perl programs in the build process. Using DBI/DBD::Pg would raise another issue - what version of libpq would it be using? Not the one in the build being tested, that's for sure. If you really want to use Perl then either a Pure Perl DBI driver (which Greg has talked about) or a thin veneer over libpq such as we used to have in contrib seems a safer way to go. cheers -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |