Re: idle connection timeout ...

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?

In response to

Responses

Browse pgsql-hackers by date

  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?