Re: Testing with concurrent sessions

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

In response to

Browse pgsql-hackers by date

  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