On Fri, 13 Nov 2009, Tom Lane wrote:
Well, if you *never* get a failure, then yeah I think you have a broken
TCP stack. The default timeouts on this sort of thing are annoyingly
long, but they aren't infinite.
Yes, this is the case. Both ends are running on GNU/Linux system and I
expect that
"Several hours" might be more like it.
Better than infinity, of course.
How long have you waited?
Two days, for example.
In any case, that complaint should be directed to your kernel vendor
not us. We do not control how long the TCP stack waits before declaring
the connection dead.
Wel
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 th
Dear Vick,
I have very similar code written in Perl, and I never observe failures
like you see after a timeout on the select call. This code has been
in production on farily busy systems for several years now.
can you tell me, which libpq and server versions you are running on?
I have constan
Dear programmers,
I am using the handy LISTEN/NOTIFY mechanism provided by PostgreSQL in my
client application, written in C with libpq. It is a simple
single-threaded single-process client (thanks to the NOTIFIcation!),
waiting for the notification using select() call with finite timeout.
Af
