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