Re: Intermittent "make check" failures on hyena

Tom Lane wrote:

>I'm noticing that buildfarm member hyena sometimes fails the parallel
>regression tests, for instance
>http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=hyena&dt=2006-07-19%2009:20:00
>
>The symptom is always that one of the tests fails entirely because
>psql couldn't connect:
>
>psql: could not connect to server: Connection refused
>    Is the server running locally and accepting
>    connections on Unix domain socket "/tmp/.s.PGSQL.55678"?
>
>It's a different test failing in each occurrence.  Sometimes there are
>ensuing failures in subsequent tests that expect the side-effects
>of the one that failed, but there's clearly a common cause here.
>
>AFAIK it is not possible for Postgres itself to cause a "connection
>refused" failure --- that's a kernel-level errno.  So what's going on
>here?  The only idea that comes to mind is that this version of Solaris
>has some very low limit on SOMAXCONN, and when the timing is just so
>it's bouncing connection requests because several of them arrive faster
>than the postmaster can fork off children.  Googling suggests that there
>are versions of Solaris with SOMAXCONN as low as 5 :-( ... but other
>pages say that the default is higher, so this theory might be wrong.
>
>What is SOMAXCONN set to on that box, anyway?  If it's tiny, I suggest
>you increase SOMAXCONN to something saner, or if you can't, run "make
>check" with MAX_CONNECTIONS=5 added to the make command.  Does the
>buildfarm script have provisions for site-local settings of this
>parameter?
>
>    
>  
>


Yes it sure does.

This is the box that Sun donated, btw.

I get: ndd /dev/tcp tcp_conn_req_max_q   => 128

Is that the Solaris equivalent of SOMAXCONN? That's low, maybe, but not 
impossibly low.

I don't have root on the box, though. For now I have set MAX_CONNECTIONS 
to 8, to provide a modest limit on parallelism. I will see if I can 
coordinate with Robert and Josh to increase the OS limits.

Thanks for the diagnosis.


cheers

andrew