8.0.0 gmake check fails if on disk, passes on ram disk....

On Fri, Jan 21, 2005 at 05:03:08PM -0700, Jeff Ross wrote:

If I put the source for 8.0.0 on disk (RAID 1) , configure, compile and
run gmake check, it fails with 33 errors, 30 of which are

! psql: could not send startup packet: Broken pipe

Somebody else using OpenBSD reported a similar problem recently.
Here's part of that thread:

http://archives.postgresql.org/pgsql-bugs/2005-01/msg00099.php

If I put the same source code up on a ram disk, configure and compile it
the same way, all 96 tests pass.

Interesting. Is this behavior consistent? What's different 'twixt
the RAID disk and the RAM disk?

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

Michael Fuhr <mike@fuhr.org> writes:

On Fri, Jan 21, 2005 at 05:03:08PM -0700, Jeff Ross wrote:

If I put the same source code up on a ram disk, configure and compile it
the same way, all 96 tests pass.

Interesting. Is this behavior consistent? What's different 'twixt
the RAID disk and the RAM disk?

If the problem is at bottom a too low processes-per-user limit, as it
was for Jean-Gerard, then maybe the RAM-disk case passes because of
different timing details. This theory is a bit of a stretch though.

In any case, we're being shown the wrong output. What I want to know is
what appears in the postmaster log when these failures happen?

regards, tom lane

Tom Lane wrote:

Michael Fuhr <mike@fuhr.org> writes:

On Fri, Jan 21, 2005 at 05:03:08PM -0700, Jeff Ross wrote:

If I put the same source code up on a ram disk, configure and compile it
the same way, all 96 tests pass.

Interesting. Is this behavior consistent? What's different 'twixt
the RAID disk and the RAM disk?

If the problem is at bottom a too low processes-per-user limit, as it
was for Jean-Gerard, then maybe the RAM-disk case passes because of
different timing details. This theory is a bit of a stretch though.

In any case, we're being shown the wrong output. What I want to know is
what appears in the postmaster log when these failures happen?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

I did a make clean, make, and gmake check this morning. Fewer tests
failed (16 of the 96) on the raid1, and again no tests failed on the ram
disk.

Rather than post it in the e-mail, I've put the postmaster.log at

http://www.openvistas.net/postmaster.log

Thanks!

Jeff Ross <jross@openvistas.net> writes:

Rather than post it in the e-mail, I've put the postmaster.log at
http://www.openvistas.net/postmaster.log

I see multiple occurrences of

LOG: could not fork new process for connection: Resource temporarily unavailable

so indeed your process limit is too low. It's curious that OpenBSD
seems more prone than other platforms to produce a "broken pipe" error
instead of reporting the error message sent back by the postmaster ...
but there is something of a race condition there, so we can't complain
too much.

I have no idea why running the tests off ramdisk would make a difference
in the probability of this failure, but it's academic. Raise your
process limit.

regards, tom lane

Tom Lane wrote:

Jeff Ross <jross@openvistas.net> writes:

Rather than post it in the e-mail, I've put the postmaster.log at
http://www.openvistas.net/postmaster.log

I see multiple occurrences of

LOG: could not fork new process for connection: Resource temporarily unavailable

so indeed your process limit is too low. It's curious that OpenBSD
seems more prone than other platforms to produce a "broken pipe" error
instead of reporting the error message sent back by the postmaster ...
but there is something of a race condition there, so we can't complain
too much.

I have no idea why running the tests off ramdisk would make a difference
in the probability of this failure, but it's academic. Raise your
process limit.

regards, tom lane

Thank you, Tom! That was indeed the problem.

Jeff Ross