Re: Testing with concurrent sessions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, andrew(at)dunslane(dot)net, peter_e(at)gmx(dot)net, david(at)kineticode(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Testing with concurrent sessions
Date: 2010-01-07 03:43:11
Message-ID: 603c8f071001061943w3c58a132o69a3d5c833e725a4@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 6, 2010 at 10:00 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2010-01-07 03:58:10 Re: libpq naming on Win64
Previous Message Robert Haas 2010-01-07 03:37:10 Re: [COMMITTERS] pgsql: Support ALTER TABLESPACE name SET/RESET ( tablespace_options ).