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