From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Copeland <greg(at)CopelandConsulting(dot)Net> |
Cc: | "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: idle connection timeout ... |
Date: | 2002-10-25 14:40:13 |
Message-ID: | 22997.1035556813@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Copeland <greg(at)CopelandConsulting(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-10-25 14:47:12 | Re: idle connection timeout ... |
Previous Message | Tom Lane | 2002-10-25 14:00:10 | Re: idle connection timeout ... |