From: | "Marc G(dot) Fournier" <scrappy(at)hub(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: idle connection timeout ... |
Date: | 2002-10-25 05:52:53 |
Message-ID: | 20021025024925.X44818-100000@hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 24 Oct 2002, Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> > just went through the new config files for v7.3, to make sure, but
> > it doens't look like we have such ... has anyone looked at adding a 'idle
> > timeout' for a postgres process? Or am I missing something in the docs?
>
> Are you looking for the backend to arbitrarily disconnect from a client
> that hasn't done anything in X amount of time? Seems to me that has
> been proposed and rejected, more than once.
>
> We already have logic that checks for loss of connectivity (see TCP
> keepalive option). If the client is *still there*, but has just not
> chosen to issue any commands lately, I have a very hard time buying
> any argument that it is the backend's province to abort the connection.
> That's a recipe for degrading reliability, not improving it.
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?
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2002-10-25 06:43:42 | Re: pg_dump and large files - is this a problem? |
Previous Message | Philip Warner | 2002-10-25 05:39:11 | Re: pg_dump and large files - is this a problem? |