Re: regression failures - further data

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: regression failures - further data
Дата
Msg-id 1823.24.211.141.25.1083883901.squirrel@www.dunslane.net
обсуждение исходный текст
Ответ на Re: regression failures - further data  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: regression failures - further data  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: regression failures - further data  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers-win32
Bruce Momjian said:
> Andrew Dunstan wrote:
>>
>> I have managed (with a lot of effort) to track down the apparent cause
>>  of the regression failures I was seeing. They appear to be directly
>> related to the degree of parallelism with which the tests are run. I
>> can  reliably get a 100% clean run on the serial tests, and on the
>> parallel  tests with MAX_CONNECTIONS=5. But if I run at
>> MAX_CONNECTIONS=10 I  (almost) always get failures, which for some
>> reason that is beyond me  start with the copy test, which isn't even
>> run in parallel with other tests.
>>
>> This is all quite worrying, and suggests that we will need to do some
>> careful stress testing before we can release this.
>>
>> Is there some W2K parameter I can tweak in the TCP stack that might
>> alleviate the problem?
>
> Is this the extra newline regression failure you were seeing?
>

No, this is running with the patch that suppresses that. Basically, for
some reason that I have been unable to find, and which leaves no log
trace, copy just stops after about 4 or 5 lines, and then there are a
bunch of consequent failures. I can't account for it yet. All I do know is
that it happens when the tests are run with high parallelism and doesn't
with no or low parallelism.

(tests are all run from MSys)

cheers

andrew



В списке pgsql-hackers-win32 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: regression failures - further data
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: regression failures - further data