Re: Assert failure found in 8.1RC1 - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Assert failure found in 8.1RC1
Date
Msg-id 436BE011.5080906@dunslane.net
Whole thread Raw
In response to Re: Assert failure found in 8.1RC1  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: Assert failure found in 8.1RC1
List pgsql-hackers

Jim C. Nasby wrote:

>On Fri, Nov 04, 2005 at 04:35:10PM -0500, Tom Lane wrote:
>  
>
>>"Jim C. Nasby" <jnasby@pervasive.com> writes:
>>    
>>
>>>Could something like that be added to regression, or maybe as a seperate
>>>test case for the buildfarm?
>>>      
>>>
>>If you don't have a self-contained, reproducible test case, it's a bit
>>pointless to suggest adding the nonexistent test case to the regression
>>suite.
>>    
>>
>
>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.

cheers

andrew


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: PG 8.1 supported platforms list
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Assert failure found in 8.1RC1