Re: PGconn gets frozen ocassionally after select() timeout
От | Marek Peca |
---|---|
Тема | Re: PGconn gets frozen ocassionally after select() timeout |
Дата | |
Msg-id | Pine.LNX.4.64.0911131753510.3778@tesla обсуждение исходный текст |
Ответ на | Re: PGconn gets frozen ocassionally after select() timeout (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PGconn gets frozen ocassionally after select() timeout
|
Список | 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.
В списке pgsql-general по дате отправления: