Re: dblnk_is_busy returns 1 for dead connecitons

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: dblnk_is_busy returns 1 for dead connecitons
Дата
Msg-id CAHyXU0x4Yi3KdW+hea2_j6a+FDbJsZ6hEybcm+UdL5e+k3f1xQ@mail.gmail.com
обсуждение исходный текст
Ответ на dblnk_is_busy returns 1 for dead connecitons  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: dblnk_is_busy returns 1 for dead connecitons  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-hackers
On Sun, Aug 2, 2020 at 7:18 PM Merlin Moncure <mmoncure@gmail.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: display offset along with block number in vacuum errors
Следующее
От: osdba
Дата:
Сообщение: Document "59.2. Built-in Operator Classes" have a clerical error?