| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Marek Peca <marek(at)duch(dot)cz> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: PGconn gets frozen ocassionally after select() timeout |
| Date: | 2009-11-13 16:39:04 |
| Message-ID: | 4026.1258130344@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Marek Peca <marek(at)duch(dot)cz> writes:
> The problem: most of time, everything works fine, hundreds of successful
> or even timed-out selects() get handled without any problem. But time to
> time (eg. after several hours), the select() call returns with a timeout
> and then, a request to the opened PQconn (simple query) gets stuck, the
> call hangs and never returns.
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. 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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Chernow | 2009-11-13 16:43:06 | Re: Libpq binary mode SELECT ... WHERE ID IN ($1) Question |
| Previous Message | Thom Brown | 2009-11-13 16:02:42 | Re: pgday.eu |