Re: Fwd: libpq: indefinite block on poll during network problems - Mailing list pgsql-general

From Dmitry Samonenko
Subject Re: Fwd: libpq: indefinite block on poll during network problems
Date
Msg-id CAFKp+3ddyt=A3qjen_2OEMTtytrTce_kAp_ZQZ8pbZDnzB9ngg@mail.gmail.com
Whole thread Raw
In response to Re: Fwd: libpq: indefinite block on poll during network problems  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fwd: libpq: indefinite block on poll during network problems
List pgsql-general
On Fri, May 30, 2014 at 6:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

[ shrug... ] This is not a bug.  It might be a feature request, but
I doubt that it's a feature anybody would be interested in implementing.

Don't count me out.
 
Adding timeouts to libpq would mean adding hard-to-test (and therefore
easy-to-break) logic paths, in service of what seems like a very debatable
design decision.  It's really the business of the network stack to decide
when a TCP connection has been lost, not libpq.  

Yes, I agree. Still, there is no way to make hints to the network stack about error-prone connection. As I've already said: setting socket's SO_RCVTIMEO and SO_SNDTIMEO would be nice. These socket parameters can be treated as PostgreSQL connection options which by default set to 0. libpq users would be able to set nonzero values if they want to.

And it's not exactly clear what recovery action libpq should take if it were to decide the
connection had been lost first.

If socket operation timeout option is considered then according to poll manual:
"A value of 0 indicates that the call timed out and no file descriptors were ready."

 and EOF is returned to the high-level function PQgetResult(...). So, I think that 'hard-to-test' logic paths would not be necessary to add - they are already there.

I think it's implicit that client should be notified about query timeout. And PQresultStatus was made to provide such info. I don't understand why client have to be blocked waiting for some miraculous result from dead/isolated server for hours. Apart from async command processing there are no alternatives to that.


BTW, you might consider using libpq's nonblock mode to push the waiting
out to the application level, and then you could just decide when you've
waited too long for yourself.

Do you mean PQsendQuery / PQisBusy / PQgetResult? Well, I wouldn't start this discussion if that was an option. Adopting async command processing would lead to starting client from scratch.
 
                        regards, tom lane

Thank you.

pgsql-general by date:

Previous
From: CS_DBA
Date:
Subject: Replication failover on windows
Next
From: Chris Hanks
Date:
Subject: row_to_json on a subset of columns.