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
[EMAIL PROTECTED] (Nathan Myers) writes:
Considering the Apache comment about some systems truncating instead
of limiting... 10xff is 16. Maybe 10239 would be a better choice,
or 16383.
Hmm. If the Apache comment is real, then that would not help on those
systems. Remember that the
On Sat, Jul 14, 2001 at 11:38:51AM -0400, Tom Lane wrote:
The state of affairs in current sources is that the listen queue
parameter is MIN(MaxBackends * 2, PG_SOMAXCONN), where PG_SOMAXCONN
is a constant defined in config.h --- it's 1, hence a non-factor,
by default, but could be
mlw [EMAIL PROTECTED] writes:
Tom Lane wrote:
Passing listen(5) would probably be sufficient for Postgres.
It demonstrably is not sufficient. Set it that way in pqcomm.c
and run the parallel regression tests. Watch them fail.
That's interesting, I would not have guessed that. I have
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
Nathan Myers wrote:
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.
BSD systems tend to claim SOMAXCONN = 5 in the header files, but
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
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?
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 clients
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
mlw [EMAIL PROTECTED] writes:
Nathan Myers wrote:
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.
BSD systems tend to claim SOMAXCONN = 5 in the header files, but *not*
to have such a small
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
Ian Lance Taylor [EMAIL PROTECTED] writes:
But I wouldn't worry about it, and I wouldn't worry about Nathan's
suggestion for making the limit configurable, because Postgres
connections don't spend time on the queue. The postgres server will
be picking them off as fast as it can. If the
Tom Lane writes:
The other concern I had could be addressed by making the listen
parameter be MIN(MaxBackends, PG_SOMAXCONN) where PG_SOMAXCONN
is set in config.h --- but now we could make the default value
really large, say 1. The only reason to change it would be
if you had a kernel
On Wed, Jul 11, 2001 at 12:26:43PM -0400, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] 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
Peter Eisentraut [EMAIL PROTECTED] 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
Peter Eisentraut [EMAIL PROTECTED] 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
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
Bruce Momjian [EMAIL PROTECTED] writes:
Don't we have maxbackends configurable at runtime.
Not after postmaster start, so passing it to the initial listen()
shouldn't be a problem.
The other concern I had could be addressed by making the listen
parameter be MIN(MaxBackends,
Tom Lane [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Nathan Myers) writes:
If you want to make it more complicated, it would be more useful to
be able to set the value lower for runtime environments where PG is
competing for OS resources with another daemon that deserves higher
19 matches
Mail list logo
