On Thu, 24 Oct 2002, Tom Lane wrote: > "Marc G. Fournier" <[EMAIL PROTECTED]> 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? ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
