| 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: | Whole Thread | Raw Message | 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 |