Thread: 8.0.0 gmake check fails if on disk, passes on ram disk....
Hi, 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 If I put the same source code up on a ram disk, configure and compile it the same way, all 96 tests pass. OS is OpenBSD 3.6. I'm currently running 7.3.5, which I'd love to upgrade but I'm a little leary until I can determine what is causing this error. Any thoughts greatly appreciated! Jeff Ross
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