ncm@zembu.com (Nathan Myers) writes:
> Considering the Apache comment about some systems truncating instead
> of limiting... 10000&0xff is 16. Maybe 10239 would be a better choice,
> or 16383.
Hmm. If the Apache comment is real, then that would not help on those
systems. Remember that the actual listen request is going to be
2*MaxBackends in practically all cases. The only thing that would save
you from getting an unexpectedly small backlog parameter in such a case
is to set PG_SOMAXCONN to 255.
Perhaps we should just do that and not worry about whether the Apache
info is accurate or not. But I'd kind of like to see chapter and verse,
ie, at least one specific system that demonstrably fails to perform the
clamp-to-255 for itself, before we lobotomize the code that way. ISTM a
conformant implementation of listen() would limit the given value to 255
before storing it into an 8-bit field, not just lose high order bits.
> After doing some more reading, I find that most OSes do not reject
> connect requests that would exceed the specified backlog; instead,
> they ignore the connection request and assume the client will retry
> later. Therefore, it appears cannot use a small backlog to shed load
> unless we assume that clients will time out quickly by themselves.
Hm. newgate is a machine on my local net that's not currently up.
$ time psql -h newgate postgres
psql: could not connect to server: Connection timed out Is the server running on host newgate and accepting
TCP/IPconnections on port 5432?
real 1m13.33s
user 0m0.02s
sys 0m0.01s
$
That's on HPUX 10.20. On an old Linux distro, the same timeout
seems to be about 21 seconds, which is still pretty long by some
standards. Do the TCP specs recommend anything particular about
no-response-to-SYN timeouts?
regards, tom lane
