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

On 05/28/2014 02:04 AM, Dmitry Samonenko wrote:
>
> On Tue, May 27, 2014 at 6:10 PM, Tom Lane <tgl@sss.pgh.pa.us
> <mailto: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.


Not sure I entirely follow what you want, but would not setting
statement_timeout work:

http://www.postgresql.org/docs/9.3/interactive/runtime-config-client.html#RUNTIME-CONFIG-CLIENT-STATEMENT

statement_timeout (integer)

     Abort any statement that takes more than the specified number of
milliseconds, starting from the time the command arrives at the server
from the client. If log_min_error_statement is set to ERROR or lower,
the statement that timed out will also be logged. A value of zero (the
default) turns this off.

     Setting statement_timeout in postgresql.conf is not recommended
because it would affect all sessions.

>
> Thank you.


--
Adrian Klaver
adrian.klaver@aklaver.com