On Fri, Jul 13, 2001 at 07:53:02AM -0400, mlw wrote:
> Zeugswetter Andreas SB wrote:
> > I liked the idea of min(MaxBackends, PG_SOMAXCONN), since there is no use in
> > accepting more than your total allowed connections concurrently.
>
> I have been following this thread and I am confused why the queue
> argument to listen() has anything to do with Max backends. All the
> parameter to listen does is specify how long a list of sockets open
> and waiting for connection can be. It has nothing to do with the
> number of back end sockets which are open.
Correct.
> If you have a limit of 128 back end connections, and you have 127
> of them open, a listen with queue size of 128 will still allow 128
> sockets to wait for connection before turning others away.
Correct.
> It should be a parameter based on the time out of a socket connection
> vs the ability to answer connection requests within that period of
> time.
It's not really meaningful at all, at present.
> 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.
> 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.
Nathan Myers
ncm@zembu.com