Re: idle connection timeout ...
| От | Marc G. Fournier |
|---|---|
| Тема | Re: idle connection timeout ... |
| Дата | |
| Msg-id | 20021025024925.X44818-100000@hub.org обсуждение исходный текст |
| Ответ на | Re: idle connection timeout ... (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: idle connection timeout ...
Re: idle connection timeout ... |
| Список | pgsql-hackers |
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?
В списке pgsql-hackers по дате отправления: