Re: inconsistant regression test results...
От | Tom Lane |
---|---|
Тема | Re: inconsistant regression test results... |
Дата | |
Msg-id | 3822.1028396357@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | inconsistant regression test results... (Vikram Kulkarni <vkulkarn@brownforces.org>) |
Ответы |
Re: inconsistant regression test results...
|
Список | pgsql-general |
Vikram Kulkarni <vkulkarn@brownforces.org> writes: > I'm trying to build+install Postgresql 7.2.1 on a OpenBSD 3.1-stable > computer. The first time I built it, the 12/79 of the regression tests > failed. This scared me, so I did a gmake distclean and then reconfigured > and rebuilt everything. This time, 14/79 tests failed. ... > This time, 11/79 test failed. This got me wondering, so I reran the > entire process (untaring, configuring, gmake'ing, and gmake check'ing) > three more times. Different results each time (14, 15, then 10). It looks to me like the primary failures are that tests abort with either psql: Server process fork() failed: Resource temporarily unavailable or psql: could not send SSL negotiation packet: Broken pipe Some later tests may then fail because they expect to find tables or data created by the un-executed earlier tests. The fork-failed messages suggest very strongly that you are running out of kernel resources when you get more than a dozen or so server processes going. Perhaps you are too low on swap space, or need to enlarge the kernel's file table size. You could try to confirm this by running the regression tests serially instead of in parallel (use the installcheck option); or you could modify the parallel_schedule file to break apart the more highly parallel test sets into smaller groups. If the tests pass that way then the problem is triggered by load, not by any specific test. Not sure about the SSL complaint, but I suspect it's the same problem at bottom. You should look in the postmaster log file that's generated by the make check run, and see if you can find what gets logged by the postmaster when one of those failures is seen on the client side. regards, tom lane
В списке pgsql-general по дате отправления: