From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Juhasz <pjuhasz(at)uhusystems(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: PQcancel may hang in the recv call |
Date: | 2016-05-19 19:32:08 |
Message-ID: | 49499.1463686328@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Peter Juhasz <pjuhasz(at)uhusystems(dot)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(dot)GD23844(at)opencloud(dot)com
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2016-05-19 19:39:29 | Re: PQcancel may hang in the recv call |
Previous Message | Christoph Moench-Tegeder | 2016-05-19 19:19:55 | Re: PostgreSQL with BDR - PANIC: could not create replication identifier checkpoint |