From: | Marek Peca <marek(at)duch(dot)cz> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: PGconn gets frozen ocassionally after select() timeout |
Date: | 2009-11-13 17:02:20 |
Message-ID: | Pine.LNX.4.64.0911131753510.3778@tesla |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 13 Nov 2009, Tom Lane wrote:
> What that sounds like is a network-level problem. In particular, if
> there's a NAT-capable router between your client and server machines,
> it's probably dropping the connection after a certain period of
> inactivity.
Yes, it probably is. The connection goes through a very fancy way,
including several NATs and VPNs and some cruel 3rd party routers. Yes, it
seems to me, that some ugly intervention of such a router is possible.
(Not sure about inactivity, since the traffic is constant and with delay
no longer than 10 minutes (in practice around 10-20 sec.) between two
NOTIFYes.)
> You may be able to fix this within Postgres by adjusting the server's
> tcp_keepalives_idle setting. If the server is on a platform that
> doesn't support changing the keepalive interval, the only recourse is to
> fix the router.
Thank you for the suggestion of tcp_keepalives_idle, I may try it.
However: I can not get the point, why does the PQexec() (or PQstatus() at
least) hang, instead of returning some error? I know, that situation with
broken TCP connection may involve long timeouts, but it could return at
least after several minutes, couldn't it?
Ordinary telnet or ssh connection will tell me, that I am writing my
characters to TCP line, which has died some time ago.
Thank you for your answers,
Marek.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-11-13 17:12:37 | Re: PGconn gets frozen ocassionally after select() timeout |
Previous Message | Andrew Chernow | 2009-11-13 16:43:06 | Re: Libpq binary mode SELECT ... WHERE ID IN ($1) Question |