Re: dblnk_is_busy returns 1 for dead connecitons

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dblnk_is_busy returns 1 for dead connecitons
Date: 2020-08-03 02:55:41
Message-ID: CAHyXU0x4Yi3KdW+hea2_j6a+FDbJsZ6hEybcm+UdL5e+k3f1xQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Aug 2, 2020 at 7:18 PM Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>
> Hackers,
>
> I have a situation that I am observing where dblink_is_busy returns 1
> even though the connection is long gone. tcp keepalives are on and
> the connection has been dead for several hours. Looking at the call
> for dblink_is_busy, I see that it is a thin wrapper to PQusBusy().
> If I attempt to call dblink_get_result(), the result comes back with
> an error mesage, 'invalid socket'. This however is not helpful since
> there is no way to probe for dead connections in dblink that appears
> to be 100% reliable. My workaround that I had been relying on was to
> call dblink_get_notify twice, which for some weird reason forced the
> connection error to the surface. However for whatever reason, that is
> not working here.
>
> In cases the connection was cancelled via dblink_cancel_query(), so in
> some scenarios connections cancelled that way seem to become 'stuck'.
> Any thoughts on this?

Correction, keepalives are probably not on, because dblink does not
have an option to set them. Also, it looks like dblink_is_busy()
calls pqConsumeInput without checking the error code. Is that safe?

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message osdba 2020-08-03 03:17:01 Document "59.2. Built-in Operator Classes" have a clerical error?
Previous Message Masahiko Sawada 2020-08-03 02:42:10 Re: display offset along with block number in vacuum errors