On Tue, May 27, 2014 at 6:10 PM, Tom Lane <t...@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. Thank you.
