From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Peter Juhasz <pjuhasz(at)uhusystems(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PQcancel may hang in the recv call |
Date: | 2016-05-19 19:13:35 |
Message-ID: | CAKFQuwaytVGn2iGrEVzN=7e7-nJ12E+6a81n4GkuZqw87Ru2Ow@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, May 19, 2016 at 10:37 AM, Peter Juhasz <pjuhasz(at)uhusystems(dot)com>
wrote:
> Hi all,
>
> this is somewhat involved so please bear with me.
>
> We've found a situation where canceling a query may cause the client to
> hang, possibly indefinitely. This can happen if the network connection
> fails in a specific way.
>
> The reason for this lies in the way the PQcancel function (which
> eventually gets called from the higher level interface's cancel
> function) is implemented. It works by opening a second connection to
> the postmaster (on the same host/port as the existing connection),
> send()-ing a cancellation message via the newly opened connection, then
> calling recv() to receive an indication that the message was processed.
>
> However, if the network fails in a way that the connection appears to
> have been established but subsequent packages are dropped silently,
> this recv() call will block.
>
> My questions:
>
> Is this known?
> Is this a bug?
> What can be done to fix or work around it, apart from applying a
> timeout wrapper the cancel operation as well?
>
>
It does sound familiar. Providing the version number(s) on which you
encountered this behavior would be helpful. Or HEAD if you have or are
testing against current code.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Cameron Smith | 2016-05-19 19:15:49 | Re: PostgreSQL with BDR - PANIC: could not create replication identifier checkpoint |
Previous Message | Alvaro Herrera | 2016-05-19 18:56:56 | Re: PostgreSQL with BDR - PANIC: could not create replication identifier checkpoint |