Testing with concurrent sessions
in [PgSql]
|
From: "Kevin Grittner" on 7 Jan 2010 17:05 Alvaro Herrera <alvherre(a)commandprompt.com> wrote: > Kevin Grittner escribi�: > >> Are we anywhere close to an agreement on what the multi-session >> psql implementation would look like? > See > http://archives.postgresql.org/message-id/8204.1207689056(a)sss.pgh.pa.us > and followups. Thanks, I had missed or forgotten this thread. It seems like it drifted more-or-less to a consensus. Does everyone agree that this thread represents the will of the community? I see the thread started at the point where Greg Stark had a patch, but by the end it was a "start over, stealing code as appropriate" situation. Has anything happened with that? Any plans? -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: "A.M." on 7 Jan 2010 17:41 On Jan 7, 2010, at 12:39 PM, Greg Sabino Mullane wrote: > I'm still *very* interested in making a libpq-less pure perl driver, > if anyone feels like funding it, let me know! :) You mean this one: http://search.cpan.org/~arc/DBD-PgPP-0.07/lib/DBD/PgPP.pm ? Cheers, M -- 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 17:56 A.M. wrote: > On Jan 7, 2010, at 12:39 PM, Greg Sabino Mullane wrote: > >> I'm still *very* interested in making a libpq-less pure perl driver, >> if anyone feels like funding it, let me know! :) >> > > You mean this one: > > http://search.cpan.org/~arc/DBD-PgPP-0.07/lib/DBD/PgPP.pm > > ? > > > It has a list of limitations as long as your arm. 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: Craig Ringer on 9 Jan 2010 20:40 On 8/01/2010 1:39 AM, Greg Sabino Mullane wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > >> 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. > > Er...why not? That's what psql uses. Because you'd have to build DBD::Pg against the new libpq, as you do psql. That means you need DBD::Pg sources and the build environment for Perl (headers etc) not just a working Perl runtime. Big difference. There's no guarantee the user's machine has the same major version of libpq and thus no guarantee that DBD::Pq can be redirected to use your custom libpq by LD_LIBRARY_PATH. It might also override the library search path with rpath linking. Building your own would be pretty much unavoidable unless you're prepared to either require the user to provide a matching version of DBD::Pg or have the tests running with whatever random version happens to be lying around. Using whatever DBD::Pg version happens to be present on the machine would be a bit of a nightmare for reproducibility of test results, and would be really unattractive for use in the standard tests. "make check fails on my some-random-distro" would become painfully common on the GENERAL list... Is bundling a Perl module in the source tree and building it as part of the Pg build a reasonable choice? Personally, I don't think so. Additionally, a dedicated testing tool like some folks have been talking about would be really handy for users who want to test their schema. I've had to write my own (in Java, or I'd be offering it) for this purpose, as psql is completely unsuitable for concurrent-run testing and I needed to show that my locking was safe and deadlock-free in some of the more complex stored procs I have. -- Craig Ringer -- 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: "Greg Sabino Mullane" on 10 Jan 2010 23:17
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >> 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. > > Er...why not? That's what psql uses. > Because you'd have to build DBD::Pg against the new libpq, as you do > psql. That means you need DBD::Pg sources and the build environment for > Perl (headers etc) not just a working Perl runtime. Big difference. Yes, but that is what I was envisioning. As you point out, that's the only sane way to make sure we have a good version of DBD::Pg with which to test. As a side effect, it put libpq through some extra paces as well. :) > Is bundling a Perl module in the source tree and building it as part of > the Pg build a reasonable choice? Personally, I don't think so. *shrug* It's different, but it's the best solution to the problem at hand. It wouldn't be built as part of Pg, only as part of the tests. > Additionally, a dedicated testing tool like some folks have been talking > about would be really handy for users who want to test their schema. > I've had to write my own (in Java, or I'd be offering it) for this > purpose, as psql is completely unsuitable for concurrent-run testing and > I needed to show that my locking was safe and deadlock-free in some of > the more complex stored procs I have. Sure, but it's the difference between waiting for someone to write something (and then dealing with the invevitable bugs, tweaks, and enhancements), or using a solid, known quantity (DBI + Test::More). - -- Greg Sabino Mullane greg(a)turnstep.com PGP Key: 0x14964AC8 201001102316 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAktKplIACgkQvJuQZxSWSsj7TQCeMOXWS+uLIZE9QbeBWPxYv/rg HhEAn0QZUzE2/8uyg5Oi+K8qL/oTeDSO =R8Az -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |