On Tue, May 27, 2014 at 6:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Would you provide some evidence for these claims? If the keepalive stuff didn't work, somebody would certainly have noticed by now.
Sure. I'll try to provide it.
Our general approach to network-error handling is that dropping a connection is a last resort, and thus it's usually inappropriate to try to force the network stack to fail more quickly than it was designed to do. While you can override the keepalive timing if you insist, we won't consider a patch that would make PG use something other than the network stack's default settings by default, if you get my drift.
regards, tom lane
Yes, I understand this. Don't get me wrong - I'm not trying to force some hard limitations on network stack. Actually, I'm trying to find a way for a libpq user to get more control on query execution. I believe that the user knows best how much time query needs to execute. After all, she has authored it. Currently, I do not see an interface to limit query execution time (on libpq part). Something like: "This query execution should take no more that 15 seconds. Alarm me with error if this timer gets exceeded". And by "query execution" I mean: "transmitting request, server execution, receiving result back". I think such feature would be nice.
Otherwise, with current libpq state (with infinite poll timeout) if you are using sync requests - you may experience uncontrolled long pauses.
