Re: Re: SOMAXCONN (was Re: Solaris source code)

On Wed, Jul 11, 2001 at 12:26:43PM -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Tom Lane writes:
> >> Right. Okay, it seems like just making it a hand-configurable entry
> >> in config.h.in is good enough for now. When and if we find that
> >> that's inadequate in a real-world situation, we can improve on it...
>
> > Would anything computed from the maximum number of allowed connections
> > make sense?
>
> [ looks at code ... ] Hmm, MaxBackends is indeed set before we arrive
> at the listen(), so it'd be possible to use MaxBackends to compute the
> parameter. Offhand I would think that MaxBackends or at most
> 2*MaxBackends would be a reasonable value.
>
> Question, though: is this better than having a hardwired constant?
> The only case I can think of where it might not be is if some platform
> out there throws an error from listen() when the parameter is too large
> for it, rather than silently reducing the value to what it can handle.
> A value set in config.h.in would be simpler to adapt for such a platform.

The question is really whether you ever want a client to get a
"rejected" result from an open attempt, or whether you'd rather they
got a report from the back end telling them they can't log in. The
second is more polite but a lot more expensive. That expense might
really matter if you have MaxBackends already running.

I doubt most clients have tested either failure case more thoroughly
than the other (or at all), but the lower-level code is more likely
to have been cut-and-pasted from well-tested code. :-)

Maybe PG should avoid accept()ing connections once it has MaxBackends
back ends already running (as hinted at by Ian), so that the listen()
parameter actually has some meaningful effect, and excess connections
can be rejected more cheaply. That might also make it easier to respond
more adaptively to true load than we do now.

> BTW, while I'm thinking about it: why doesn't pqcomm.c test for a
> failure return from the listen() call? Is this just an oversight,
> or is there a good reason to ignore errors?

The failure of listen() seems impossible. In the Linux, NetBSD, and
Solaris man pages, none of the error returns mentioned are possible
with PG's current use of the function. It seems as if the most that
might be needed now would be to add a comment to the call to socket()
noting that if any other address families are supported (besides
AF_INET and AF_LOCAL aka AF_UNIX), the call to listen() might need to
be looked at. AF_INET6 (which PG will need to support someday)
doesn't seem to change matters.

Probably if listen() did fail, then one or other of bind(), accept(),
and read() would fail too.

Nathan Myers
ncm(at)zembu(dot)com