Re: Assert failure found in 8.1RC1

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Assert failure found in 8.1RC1
Дата
Msg-id 436BE011.5080906@dunslane.net
обсуждение исходный текст
Ответ на Re: Assert failure found in 8.1RC1  ("Jim C. Nasby" <jnasby@pervasive.com>)
Ответы Re: Assert failure found in 8.1RC1  ("Jim C. Nasby" <jnasby@pervasive.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: PG 8.1 supported platforms list
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Assert failure found in 8.1RC1