On Thu, 24 Oct 2002, Tom Lane wrote:
> "Marc G. Fournier" <scrappy@hub.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?
