Re: Cygwin PostgreSQL Regression Test Problems (Revisited) - Mailing list pgsql-ports

From Tom Lane
Subject Re: Cygwin PostgreSQL Regression Test Problems (Revisited)
Date
Msg-id 8565.986233454@sss.pgh.pa.us
Whole thread Raw
In response to Re: Cygwin PostgreSQL Regression Test Problems (Revisited)  (Jason Tishler <Jason.Tishler@dothill.com>)
Responses Re: Cygwin PostgreSQL Regression Test Problems (Revisited)  (Jason Tishler <Jason.Tishler@dothill.com>)
List pgsql-ports
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.

>> 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?

            regards, tom lane

pgsql-ports by date:

Previous
From: Jason Tishler
Date:
Subject: Re: Cygwin PostgreSQL Regression Test Problems (Revisited)
Next
From: Jason Tishler
Date:
Subject: Re: Re: [PATCHES] patch for minor Win32 makefile bug