| From: | Greg Copeland <greg(at)CopelandConsulting(dot)Net> |
|---|---|
| To: | "Marc G(dot) Fournier" <scrappy(at)hub(dot)org> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: idle connection timeout ... |
| Date: | 2002-10-25 13:47:42 |
| Message-ID: | 1035553688.10003.2275.camel@mouse.copelandconsulting.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-10-25 14:00:10 | Re: idle connection timeout ... |
| Previous Message | Stephan Szabo | 2002-10-25 12:57:22 | Re: [HACKERS] Security question : Database access control |