Re: idle connection timeout ...

Yes, my comments related to useing db/user limits to control the number
of persistent connections.  From an ISP perspective, I can see value in
user/db limits.

---------------------------------------------------------------------------

Marc G. Fournier wrote:
> On Fri, 25 Oct 2002, Bruce Momjian wrote:
> 
> > Tom Lane wrote:
> > > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > >> Well, there are two different things here.  I agree that if an app
> > > >> is going to use persistent connections, it should be the app's
> > > >> responsibility to manage them.  But a per-database, as opposed to
> > > >> installation-wide, limit on number of connections seems like a
> > > >> reasonable idea.  Note that the limit would result in new connections
> > > >> being rejected, not old ones being summarily cut.
> > >
> > > > But then the app is going to keep trying to connect over and over unless
> > > > it knows something about why it can't connect.
> > >
> > > So?  If it hits the installation-wide limit, you'll have the same
> > > problem; and at that point the (presumably runaway) app would have
> > > sucked up all the connections, denying service to other apps using other
> > > databases.  I think Marc's point here is to limit his exposure to
> > > misbehavior of any one client app, in a database server that is serving
> > > multiple clients using multiple databases.
> >
> > What I am saying is that using the backend to throttle per-db
> > connections may not work too well because they will just keep retrying.
> 
> Okay, but also bear in mind that alot of the time, when I'm bringign up
> stuff like this, I'm coming from the "ISP" perspective ... if I have one
> client that is using up all 512 connections on the server, none of my
> other clients are getting any connections ...
> 
> Yes, the client should have tested his code better, but I want to be able
> to put 'limits' to make it so that everyone isn't affected by ones mistake
> ...
> 
> > I realize that the total limit can be hit too, but I assume that limit
> > is set so it will not be hit (it's a resource tradeoff), while the
> > per-db limit is there to try to throttle back the persistent
> > connections.
> 
> Nope, the per-db limit is there to try and eliminate the impact of one
> client/application from essentially creating a DoS for all other
> database/clients ...
> 
> > Basically, total connections is to be set larger than you think you will
> > ever need, while you expect per-db to be hit, and if something keeps
> > trying to connect and failing, we may get very bad connection
> > performance for other backends.  This is where doing the limiting on the
> > persistent connection end would be a better solution.
> 
> Agreed, but unless you have control over both the client and server sides,
> its not possible ...
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073