Re: PQcancel may hang in the recv call - Mailing list pgsql-general

From Tom Lane
Subject Re: PQcancel may hang in the recv call
Date
Msg-id 49499.1463686328@sss.pgh.pa.us
Whole thread Raw
In response to PQcancel may hang in the recv call  (Peter Juhasz <pjuhasz@uhusystems.com>)
Responses Re: PQcancel may hang in the recv call  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: PQcancel may hang in the recv call  (Peter Juhasz <pjuhasz@uhusystems.com>)
List pgsql-general
Peter Juhasz <pjuhasz@uhusystems.com> writes:
> 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.
> ...
> 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.

Hmm.  I would expect the recv to eventually fail based on TCP timeouts,
but I agree that that would be much longer than you'd typically wish
to wait.

> Is this known?

I do not recall anyone ever reporting something similar --- and that code
has been like that for a long time.

> Is this a bug?

I wouldn't call it that exactly.  There might be an opportunity for
improvement here, but it's not very clear what.  Just introducing a
timeout would likely create more problems than it fixes, considering the
evident rarity of the problem.  The race condition hazard that the recv()
is trying to prevent is definitely real: we used to not have that, and
we got bug reports, cf
http://www.postgresql.org/message-id/flat/20030915070801.GD23844@opencloud.com

            regards, tom lane


pgsql-general by date:

Previous
From: Christoph Moench-Tegeder
Date:
Subject: Re: PostgreSQL with BDR - PANIC: could not create replication identifier checkpoint
Next
From: "David G. Johnston"
Date:
Subject: Re: PQcancel may hang in the recv call