On Fri, 4 Nov 2005, Jim C. Nasby wrote:
> On Fri, Nov 04, 2005 at 05:26:25PM -0500, Andrew Dunstan wrote:
>>> Well, for things like race conditions I don't know that you can create
>>> reproducable test cases. My point was that this bug was exposed by
>>> databases with workloads that involved very high transaction rates. I
>>> know in the case of my client this is due to some sub-optimal design
>>> decisions, and I believe the other case was similar. My suggestion is
>>> that having a test that involves a lot of row-by-row type operations
>>> that generate a very high transaction rate would help expose these kinds
>>> of bugs.
>>>
>>> Of course if someone can come up with a self-contained reproducable test
>>> case for this race condition that would be great as well. :)
>>>
>>>
>>
>> These conditions make it quite unsuitable for buildfarm, which is
>> designed as a thin veneer over the postgres build process, and intended
>> to run anywhere you can build postgres.
>>
>> Maybe you could use one of the Linux labs, since your client is on RHEL.
>
> I'm not worried about my client, I'm just thinking of a way to better
> ferret out bugs like this. And there's no real reason why something like
> this couldn't be part of regression, or an additional build target.
For all the talk about "couldn't it be part of regression", I haven't seen
anyone submit a patch that would test for it ... since I believe both you
and Tom have both stated that "for things like race conditions, I don't
know that you can create reproducable cases", can you submit a patch for
how you propose this should be added to the regression tests?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664