Re: Cygwin PostgreSQL Regression Test Problems (Revisited)

Tom,

On Mon, Apr 02, 2001 at 03:50:55PM -0400, Tom Lane wrote:
> Jason Tishler <Jason.Tishler@dothill.com> writes:
> > 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.
>
> My feeling is that we should leave it in place for 7.1 in any case.
> Once there's a shipping Cygwin version that maps the error number
> correctly, we can back out the patch so that Cygwin is treated more
> like other platforms.

OK, the above plan is reasonable.

> > 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.
>
> This page only talks about NT; what of other flavors of Windows?  Cygwin
> runs on more than NT, doesn't it?

Yes, it runs on 2000, 9X/Me, and even XP.  Unfortunately, I couldn't
(easily) find the limits for these versions.  My WAG is that 2000 and
XP will be the same or similar to NT.  I am not concerned about 9X/Me
because I find them unusable for other reasons.

> Interesting point here: a copy of Postgres compiled on NT WS would
> presumably see SOMAXCONN = 5 in the system headers.  If the executable
> is then moved to NT Server, it would fail to take advantage of the
> higher queue limit.

Actually, even if compiled on NT Server, SOMAXCONN is it set to 5 due to
Cygwin's socket.h.

> Do we need to hardwire a hack to use the larger
> value always on Windows?

Sounds like a good idea, but the effort only seems reasonable if we can
conclude that Windows will really take advantage of it.

> > 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?
>
> Yes (although that's still hypothesis, not the proven cause of failure).
>
> I still suspect there's something else going on here, anyway.  SOMAXCONN
> is nominally 5 on quite a lot of Unixen, but we've only heard reports of
> transient "make check" connect failures on Windows.  Why is Windows so
> much more prone to show this problem?

I don't know!  I've been banging my head to find out why and my head is
starting to hurt... :,)

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