Re: Blocking connection and timeout problem

Used to have this problem also with pgadmin connections, that didn't close
some sessions remain there, for a period, and you must kill them to continue

without a restart of the service.

scenery:
pgsql >= 7.4.3 , not tested on >=8
pgadmin <= 1.0.2

On other layer of this issue, this should be also related with some in deep
tcp/ip settings.
ie, I know that in order to keep an <idle> ssh session open for a longer
time, you shall touch some values somewhere *not* in the main ssh_config
file. (a global parameter for the OS) And this will keep your session open
for a longer time.

If this is particular for every OS, that could explain a longer time on your
case, and 1 or 2 hours in Tom's case.

Anyway, I would like to hear a little bit about this, cause it's a little
bit difficult to find such cases,
we always end on the problem lacking, without a previous warn. (and that is
bad, for a DBA at least).

Regards,
Guido

On 8/3/05, KÖPFERL Robert <robert(dot)koepferl(at)sonorys(dot)at> wrote:
>
>
>
> |-----Original Message-----
> |From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> |Sent: Mittwoch, 03. August 2005 16:38
> |To: KÖPFERL Robert
> |Cc: pgsql-admin(at)postgresql(dot)org
> |Subject: Re: [ADMIN] Blocking connection and timeout problem
> |
> |
> |=?iso-8859-1?Q?K=D6PFERL_Robert?= <robert(dot)koepferl(at)sonorys(dot)at> writes:
> |> Why is that? Why isn't client A's transaction detected as dead ?
> |
> |It will be eventually, when the TCP connection times out. The standard
> |timeout is generally an hour or two :-(
>
> Seems not like so. I waited for two hours and it still existed.
>
> But non-the-less. Can this timeout be configured to be less?
>
> |
> | regards, tom lane
> |
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

--
"Adopting the position that you are smarter than an automatic
optimization algorithm is generally a good way to achieve less
performance, not more" - Tom Lane.