Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux