Nathan Myers wrote:
> > There are two was to think about this. Either you make this parameter
> > tunable to give a proper estimate of the usability of the system, i.e.
> > tailor the listen queue parameter to reject sockets when some number
> > of sockets are waiting, or you say no one should ever be denied,
> > accept everyone and let them time out if we are not fast enough.
> >
> > This debate could go on, why not make it a parameter in the config
> > file that defaults to some system variable, i.e. SOMAXCONN.
>
> With postmaster's current behavior there is no benefit in setting
> the listen() argument to anything less than 1000. With a small
> change in postmaster behavior, a tunable system variable becomes
> useful.
>
> But using SOMAXCONN blindly is always wrong; that is often 5, which
> is demonstrably too small.
It is rumored that many BSD version are limited to 5.
>
> > BTW: on linux, the backlog queue parameter is silently truncated to
> > 128 anyway.
>
> The 128 limit is common, applied on BSD and Solaris as well.
> It will probably increase in future releases.
This point I am trying to make is that the parameter passed to listen() is OS
dependent, on both what it means and its defaults. Trying to tie this to
maxbackends is not the right thought process. It has nothing to do, at all,
with maxbackends.
Passing listen(5) would probably be sufficient for Postgres. Will there ever be
5 sockets in the listen() queue prior to "accept()?" probably not. SOMAXCONN
is a system limit, setting a listen() value greater than this, is probably
silently adjusted down to the defined SOMAXCONN.
By making it a parameter, and defaulting to SOMAXCONN, this allows the maximum
number of connections a system can handle, while still allowing the DBA to fine
tune connection behavior on high load systems.