Re: TCP keepalive support for libpq - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: TCP keepalive support for libpq
Date
Msg-id db471ace1002120140m1e828bcdmc394300e7c41378c@mail.gmail.com
Whole thread Raw
In response to Re: TCP keepalive support for libpq  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: TCP keepalive support for libpq
List pgsql-hackers
> <peter.geoghegan86@gmail.com> wrote:
>> Why hasn't libpq had keepalives for years?
>
> I guess that it's because keepalive doesn't work as expected
> in some cases. For example, if the network outage happens
> before a client sends some packets, keepalive doesn't work,
> then it would have to wait for a long time until it detects
> the outage. This is the specification of linux kernel. So
> a client should not have excessive expectations of keepalive,
> and should have another timeout like QueryTimeout of JDBC.

In my experience, the problems described are common when using libpq
over any sort of flaky connection, which I myself regularly do (not
just with Slony, but with a handheld wi-fi PDT application, where
libpq is used without any wrapper). The slony docs say it takes about
2 hours for the problem to correct itself, but I have found that it
may take a lot longer, perhaps because I have a hybrid Linux/Windows
Slony cluster.

> keepalive doesn't work,
> then it would have to wait for a long time until it detects
> the outage.

I'm not really sure what you mean. In this scenario, would it take as
long as it would have taken had keepalives not been used?

I strongly welcome anything that can ameliorate these problems, which
are probably not noticed by the majority of users, but are a real
inconvenience when they do arise.

Regards,
Peter Geoghegan


pgsql-hackers by date:

Previous
From: Federico Di Gregorio
Date:
Subject: Re: Confusion over Python drivers {license}
Next
From: Heikki Linnakangas
Date:
Subject: Re: testing cvs HEAD - HS/SR - cannot stat