Tom Lane wrote:
> Greg Copeland <greg@CopelandConsulting.Net> writes:
> > On Fri, 2002-10-25 at 00:52, Marc G. Fournier wrote:
> >> Ya, I've thought that one through ... I think what I'm more looking at is
> >> some way of 'limiting' persistent connections, where a server opens n
> >> connections during a spike, which then sit idle indefinitely since it was
> >> one fo those 'slashdot effect' kinda spikes ...
> >>
> >> Is there any way of the 'master process' *safely/accurately* knowing,
> >> through the shared memory link, the # of connections currently open to a
> >> particular database? So that a limit could be set on a per db basis, say
> >> as an additional arg to pg_hba.conf?
>
> > Well, if you're application is smart enough to know it needs to
> > dynamically add connections, it should also be smart enough to tear them
> > down after some idle period. I agree with Tom. I think that sounds
> > like application domain.
>
> 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.
-- 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