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
Re: regression failures - further data |
Список | 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 по дате отправления: