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

From Tom Lane
Subject Re: Fwd: libpq: indefinite block on poll during network problems
Date
Msg-id 8827.1401199836@sss.pgh.pa.us
Whole thread Raw
In response to Fwd: libpq: indefinite block on poll during network problems  (Dmitry Samonenko <shreddingwork@gmail.com>)
Responses Re: Fwd: libpq: indefinite block on poll during network problems  (Dmitry Samonenko <shreddingwork@gmail.com>)
List pgsql-general
Dmitry Samonenko <shreddingwork@gmail.com> writes:
> On Tue, May 27, 2014 at 2:35 PM, Albe Laurenz <laurenz.albe@wien.gv.at>wrote:
>> In PostgreSQL you can handle the problem of dying connections by setting
>> the
>> tcp_keepalives_* parameters (see
>> http://www.postgresql.org/docs/current/static/runtime-config-connection.html
>> ).
>>
>> That should take care of the problem, right?

> I am afraid it won't help:

> 1. AFAIK, in Linux TCP keepalive is used on idle connections only. If not
> all data is transmitted - connection is not idle - keep alive timer is not
> started.
> 2. POLLHUP mask is used (while setting poll fds) to catch keep alive
> timeout. Sadly, libpq sets (POLLIN | POLLERR).

Would you provide some evidence for these claims?  If the keepalive stuff
didn't work, somebody would certainly have noticed by now.

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


pgsql-general by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: hidden junk files in ...data/base/oid/
Next
From: Meik Weißbach
Date:
Subject: pg_upgrade from 8.3 to 9.1 and Flag --disable-integer-datetimes