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

> 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.

One of us has probably misunderstood the listen parameter.
It only limits the number of clients that can connect concurrently.
It has nothing to do with the number of clients that are already connected.
It sort of resembles a maximum queue size for the accept loop.
Incoming connections fill the queue, accept frees the queue by taking the 
connection to a newly forked backend.

Andreas

On Thu, Jul 12, 2001 at 10:14:44AM +0200, Zeugswetter Andreas SB wrote:
> 
> > 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.
> 
> One of us has probably misunderstood the listen parameter.

I don't think so.

> It only limits the number of clients that can connect concurrently.
> It has nothing to do with the number of clients that are already 
> connected.  It sort of resembles a maximum queue size for the accept 
> loop.  Incoming connections fill the queue, accept frees the queue by
> taking the connection to a newly forked backend.

The MaxBackends constant and the listen() parameter have no effect 
until the number of clients already connected or trying to connect
and not yet noticed by the postmaster (respectively) exceed some 
threshold.  We would like to choose such thresholds so that we don't 
promise service we can't deliver.

We can assume the administrator has tuned MaxBackends so that a
system with that many back ends running really _is_ heavily loaded.  
(We have talked about providing a better measure of load than the
gross number of back ends; is that on the Todo list?)

When the system is too heavily loaded (however measured), any further 
login attempts will fail.  What I suggested is, instead of the 
postmaster accept()ing the connection, why not leave the connection 
attempt in the queue until we can afford a back end to handle it?  
Then, the argument to listen() will determine how many attempts can 
be in the queue before the network stack itself rejects them without 
the postmaster involved.

As it is, the listen() queue limit is not useful.  It could be made
useful with a slight change in postmaster behavior.

Nathan Myers
ncm@zembu.com

Nathan Myers writes:

> When the system is too heavily loaded (however measured), any further
> login attempts will fail.  What I suggested is, instead of the
> postmaster accept()ing the connection, why not leave the connection
> attempt in the queue until we can afford a back end to handle it?

Because the new connection might be a cancel request.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter

On Thu, Jul 12, 2001 at 11:08:34PM +0200, Peter Eisentraut wrote:
> Nathan Myers writes:
> 
> > When the system is too heavily loaded (however measured), any further
> > login attempts will fail.  What I suggested is, instead of the
> > postmaster accept()ing the connection, why not leave the connection
> > attempt in the queue until we can afford a back end to handle it?
> 
> Because the new connection might be a cancel request.

Supporting cancel requests seems like a poor reason to ignore what
load-shedding support operating systems provide.  

To support cancel requests, it would suffice for PG to listen at 
another socket dedicated to administrative requests.  (It might 
even ignore MaxBackends for connections on that socket.)

Nathan Myers
ncm@zembu.com