Re: Cygwin PostgreSQL Regression Test Problems (Revisited)

I wrote:
> 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?

Hm, maybe I need to take this back. Some poking around shows that
SOMAXCONN is defined as 128 on Linux, 20 on HPUX, which are the
platforms I've tested most. As an experiment I reduced the listen()
parameter to 5 on HPUX, and bingo: I get connection-refused failures
in "make check". So it seems that Windows' behavior is not so out of
line after all. We would probably see similar failures on BSD-derived
systems, since BSD systems traditionally set SOMAXCONN to 5. (Any
BSD partisans able to check this?)

I do not think that we should change "make check" to avoid this issue.
If you are on a platform that has a problem with supporting lots of
parallel connection requests, it seems to me that you'd best know about
that limitation, and "make check" is doing you a service by pointing
out the problem.

What I do think we should consider is whether to believe SOMAXCONN
unconditionally, or to use a large value in the listen() call no matter
what the system headers claim SOMAXCONN is. This would avoid
sillinesses such as using an NT-Workstation limit on an NT-Server
machine. The only risk I can see is that some platforms might reject
as erroneous a listen() parameter that's more than they are prepared to
support. The Unix man pages I have access to claim that a too-large
listen() parameter will be clamped to the kernel's SOMAXCONN without
raising an error, but does anyone have an idea whether that behavior
is universal?

In the longer term, we should think about whether we can reduce the
postmaster's connection service delay. Someone recently suggested
that the postmaster should fork a child immediately upon receiving
a connection, and let the child work on the authentication process
while the parent goes right back to accept(). I'm not sure if that
would help "make check" very much, since it's presumably not running
anything more complex than "trust" authentication anyway. But it
should eliminate auth delays caused by SSL, malfunctioning ident
daemons, and sundry other problems.

regards, tom lane