Testing with concurrent sessions
in [PgSql]
|
From: Tom Lane on 7 Jan 2010 12:19 "David E. Wheeler" <david(a)kineticode.com> writes: > On Jan 7, 2010, at 9:08 AM, Tom Lane wrote: >> Right, but to my mind "building from a tarball" needs to include the >> ability to run the regression tests on what you built. So injecting >> Perl into that is moving the goalposts on build requirements. > In that case, there's nothing for it except concurrent psql. Unless we are prepared to define concurrency testing as something separate from the basic regression tests. Which is kind of annoying but perhaps less so than the alternatives. It certainly seems to me to be the kind of thing you wouldn't need to test in order to have confidence in a local build. 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: "David E. Wheeler" on 7 Jan 2010 12:22 On Jan 7, 2010, at 9:19 AM, Tom Lane wrote: >> In that case, there's nothing for it except concurrent psql. > > Unless we are prepared to define concurrency testing as something > separate from the basic regression tests. Which is kind of annoying but > perhaps less so than the alternatives. It certainly seems to me to > be the kind of thing you wouldn't need to test in order to have > confidence in a local build. I was rather assuming that was what we were talking about here, since we have in the past discussed testing things like dump and restore, which would require something like Perl to handle multiple processes, and wouldn't work very well for a regular release. I think if we have the ability to add tests that are not distributed, it gives us a lot more freedom and opportunity to test things that are not currently well-tested. 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: "Greg Sabino Mullane" on 7 Jan 2010 12:34 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > Unless we are prepared to define concurrency testing as something > separate from the basic regression tests. Which is kind of annoying but > perhaps less so than the alternatives. It certainly seems to me to > be the kind of thing you wouldn't need to test in order to have > confidence in a local build. I thought we were leaning towards something separate. - -- Greg Sabino Mullane greg(a)turnstep.com PGP Key: 0x14964AC8 201001071234 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAktGGxYACgkQvJuQZxSWSsgG0gCfZ4eTpXd/97p3zSJpLqGhKMh6 8nMAoJ2lQUaCWNVeSPDU8fq7VnkO0s4C =xBOo -----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
From: "Greg Sabino Mullane" on 7 Jan 2010 12:39 -----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. As for those advocating using a custom C program written using libpq - that's basically what DBI/DBD::Pg ends up being! Only with a shiny Perl outside and years of real-world testing and usage. > 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. I'm still *very* interested in making a libpq-less pure perl driver, if anyone feels like funding it, let me know! :) - -- Greg Sabino Mullane greg(a)turnstep.com PGP Key: 0x14964AC8 201001071236 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAktGHF0ACgkQvJuQZxSWSsiFmACfUJbRDUJGvDTJNjgj/dyQKVCA tZwAn2fiXKNWbWzYXobrHZjeE8aSSiVv =sGzK -----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
From: "Greg Sabino Mullane" on 7 Jan 2010 13:16
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >> 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.) As a counterargument, I'll point out that this won't be as critical as zic, especially if we're talking about an additional/optional set of tests. Also, Tim Bunce and I are right here, so the maintenance should not be that bad (and I'd hazard that a lot more people in the community know Perl/DBI than zic or stemmers). - -- Greg Sabino Mullane greg(a)turnstep.com PGP Key: 0x14964AC8 201001071315 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAktGJNQACgkQvJuQZxSWSshoHwCg9urTTT19m55soiIjuYKKuB5L PjYAoJbDAe7j4xsxsSFfVEkYDFpTjKE9 =48oW -----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 |