Re: Cygwin PostgreSQL Regression Test Problems (Revisited)

Tom,

On Mon, Apr 02, 2001 at 01:44:14PM -0400, Tom Lane wrote:
> Jason Tishler <Jason.Tishler@dothill.com> writes:
> > In both cases there are no hangs, just the error messages are different.
> > Unfortunately, for the non-blocking case the error message is cryptic.
> > I tried tracking down error "10061" which comes from getsockopt(), but
> > I was unsuccessful.  Is there any way to improve the readability of this
> > error message?
>
> I'm inclined to leave the blocking-connect change in there just to
> suppress that peculiar error message.  No, I have no idea where it's
> coming from, either.

I just figured out what is error 10061 -- it is WSAECONNREFUSED, Winsock's
version of ECONNREFUSED.  I just submitted a patch to Cygwin that maps
getsockopt optval's from the Winsock versions to their corresponding
errno values.  I just tried psql with an unconnected socket file and
psql displayed:

    psql: PQconnectPoll() -- connect() failed: Connection refused
        Is the postmaster running locally
        and accepting connections on Unix socket '/tmp/.s.PGSQL.5432'?

as desired.

If interested, see the following for details:

    http://www.cygwin.com/ml/cygwin-patches/2001-q2/msg00003.html

If my Cygwin patch is accepted, I'll let the list know.  At that time, I
think that the fe-connect.c change should be backed out.

> >> However Hiroshi says later that he already tried [ raising SOMAXCONN ]
>
> > Even if it worked, this would have just pushed the problem instead of
> > really fixing it.
>
> If the problem were overflow of the accept queue, then raising the
> listen() parameter ought to fix it, assuming that Windows does actually
> allow larger values for the parameter.  Given that we are only hearing
> this problem reported on Windows, I have a sneaking suspicion that the
> effective queue length limit is 1 on that platform no matter what we
> pass to listen().  Is there anyone we might ask about concurrent
> connection-request handling on Windows?

In digging some more through the MSDN, I found out the backlog limit
on NT 4.0 Workstation and Server is 5 and 200, respectively.  So, it
would appears that NT is really using this parameter.  If interested,
see the following for more details:

    http://support.microsoft.com/support/kb/articles/Q127/1/44.asp

When running the parallel_schedule, as many as 18 psql's are trying to
connect to postmaster.  Isn't it conceivable that more than 6 are trying
to connection concurrently?

Thanks,
Jason

Jason

--
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com