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