Re: Fwd: libpq: indefinite block on poll during network problems

On Tue, May 27, 2014 at 6:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.