Testing with concurrent sessions
in [PgSql]
|
From: "Kevin Grittner" on 6 Jan 2010 21:43 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. Well, if that's the consensus, I have to choose between trying to implement multi-session psql and using testing which can't carry over to long-term regular use. Are we anywhere close to an agreement on what the multi-session psql implementation would look like? (If not I can put something forward.) -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: Robert Haas on 6 Jan 2010 21:49 On Wed, Jan 6, 2010 at 9:26 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> It just seems crazy to me to try to test anything without proper >> language bindings. Opening a psql session and parsing the results >> seems extraordinarily painful. I wonder if it would make sense write >> a small wrapper program that uses libpq and dumps out the results in a >> format that is easy for Perl to parse. > >> Another idea would be to make a set of Perl libpq bindings that is >> simpler than DBD::Pg and don't go through DBI. If we put those in the >> main source tree (perhaps as a contrib module) they would be available >> wherever we need them. > > 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 suppose that depends on the context. I'm not exactly sure what Kevin's goal is here. For basic regression tests, yeah, we'd probably like to keep that Perl-free. For more complex testing, I think using Perl makes sense. Or to put the shoe on the other foot, if we DON'T allow the use of Perl for more complex testing, then we're probably not going to have any more complex tests. If we use a hypothetical concurrent psql implementation to run the tests, how will we analyze the results? It's no secret that the current regression tests are fairly limited, in part because the only thing we can do with them is diff the output against one or two "known good" results. ....Robert -- 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 6 Jan 2010 22:00 Robert Haas wrote: > I'm not exactly sure what Kevin's goal is here. I think it would be insane to try to do something like serializable isolation mode without having regression tests. I would want more tests than could reasonably go into the 'make check' suite to support development, but it would be very good to have some go in there. > For basic regression tests, yeah, we'd probably like to keep that > Perl-free. OK. Is parallel psql the only reasonable option? > For more complex testing, I think using Perl makes sense. Or to put > the shoe on the other foot, if we DON'T allow the use of Perl for > more complex testing, then we're probably not going to have any > more complex tests. Do you envision some test suite committed to CVS beyond the 'make check' tests, for "on demand" testing at a more rigorous level? Am I missing something that's already there? -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: Alvaro Herrera on 6 Jan 2010 22:05 Kevin Grittner escribi�: > Well, if that's the consensus, I have to choose between trying to > implement multi-session psql and using testing which can't carry over > to long-term regular use. Are we anywhere close to an agreement on > what the multi-session psql implementation would look like? (If not > I can put something forward.) See http://archives.postgresql.org/message-id/8204.1207689056(a)sss.pgh.pa.us and followups. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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: Robert Haas on 6 Jan 2010 22:43
On Wed, Jan 6, 2010 at 10:00 PM, Kevin Grittner <Kevin.Grittner(a)wicourts.gov> wrote: >> For basic regression tests, yeah, we'd probably like to keep that >> Perl-free. > > OK. Is parallel psql the only reasonable option? It seems so, assuming you're willing to concede that it is a reasonable option in the first place. >> For more complex testing, I think using Perl makes sense. Or to put >> the shoe on the other foot, if we DON'T allow the use of Perl for >> more complex testing, then we're probably not going to have any >> more complex tests. > > Do you envision some test suite committed to CVS beyond the 'make > check' tests, for "on demand" testing at a more rigorous level? > Am I missing something that's already there? Personally, I tend to think that to test this well you are going to need a test suite written in a scripting language. Whether or not that gets committed to CVS is a political question, but I would be in favor of it (assuming it's good, of course). Maybe you will find that you can do it all with concurrent psql, but (1) I'm not convinced and (2) if that's your plan, does that mean you're going to do nothing until someone implements concurrent psql? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |