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.koepferl@sonorys.at> wrote:
|-----Original Message-----
|From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
|Sent: Mittwoch, 03. August 2005 16:38
|To: KÖPFERL Robert
|Cc: pgsql-admin@postgresql.org
|Subject: Re: [ADMIN] Blocking connection and timeout problem
|
|
|KÖPFERL Robert <robert.koepferl@sonorys.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.