From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Dmitry Samonenko <shreddingwork(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Fwd: libpq: indefinite block on poll during network problems |
Date: | 2014-05-28 13:46:21 |
Message-ID: | 5385E8AD.5060909@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 05/28/2014 02:04 AM, Dmitry Samonenko wrote:
>
> On Tue, May 27, 2014 at 6:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> <mailto: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.
Not sure I entirely follow what you want, but would not setting
statement_timeout work:
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(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2014-05-28 14:15:01 | Re: Error while upgrading from 8.4 to 9.3 |
Previous Message | Leonardo M. Ramé | 2014-05-28 13:19:24 | Error while upgrading from 8.4 to 9.3 |