On Fri, May 30, 2014 at 6:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
[ shrug... ] This is not a bug. It might be a feature request, but I doubt that it's a feature anybody would be interested in implementing.
Don't count me out.
Adding timeouts to libpq would mean adding hard-to-test (and therefore easy-to-break) logic paths, in service of what seems like a very debatable design decision. It's really the business of the network stack to decide when a TCP connection has been lost, not libpq.
Yes, I agree. Still, there is no way to make hints to the network stack about error-prone connection. As I've already said: setting socket's SO_RCVTIMEO and SO_SNDTIMEO would be nice. These socket parameters can be treated as PostgreSQL connection options which by default set to 0. libpq users would be able to set nonzero values if they want to.
And it's not exactly clear what recovery action libpq should take if it were to decide the connection had been lost first.
If socket operation timeout option is considered then according to poll manual: "A value of 0 indicates that the call timed out and no file descriptors were ready."
and EOF is returned to the high-level function PQgetResult(...). So, I think that 'hard-to-test' logic paths would not be necessary to add - they are already there.
I think it's implicit that client should be notified about query timeout. And PQresultStatus was made to provide such info. I don't understand why client have to be blocked waiting for some miraculous result from dead/isolated server for hours. Apart from async command processing there are no alternatives to that.
BTW, you might consider using libpq's nonblock mode to push the waiting out to the application level, and then you could just decide when you've waited too long for yourself.
Do you mean PQsendQuery / PQisBusy / PQgetResult? Well, I wouldn't start this discussion if that was an option. Adopting async command processing would lead to starting client from scratch.