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

On Fri, May 30, 2014 at 6:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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."

pqWaitTimed is already adapted for a such case:
http://doxygen.postgresql.org/fe-misc_8c.html#adcec54ce0a51d2a0a9f2f4ff5df071d3
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.