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.
regards, tom lane
