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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073