From: | "Andrew Dunstan" <andrew(at)dunslane(dot)net> |
---|---|
To: | <pgsql-hackers-win32(at)postgresql(dot)org> |
Subject: | Re: regression failures - further data |
Date: | 2004-05-06 22:51:41 |
Message-ID: | 1823.24.211.141.25.1083883901.squirrel@www.dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-05-06 23:03:27 | Re: regression failures - further data |
Previous Message | Bruce Momjian | 2004-05-06 22:09:52 | Re: regression failures - further data |