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