From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Testing with concurrent sessions |
Date: | 2010-01-07 17:22:45 |
Message-ID: | 9B4AB52C-A6F6-48FF-8DED-BFBA8BA5EC94@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-01-07 17:23:32 | Re: Streaming replication and postmaster signaling |
Previous Message | Tom Lane | 2010-01-07 17:19:50 | Re: Testing with concurrent sessions |