Re: Queries that should be canceled will get stuck on secure_write function
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, 蔡梦娟(玊于) <mengjuan.cmj@alibaba-inc.com>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-08-27T20:07:02Z
Lists: pgsql-hackers
On Fri, Aug 27, 2021 at 3:24 PM Andres Freund <andres@anarazel.de> wrote: > I wonder if we could improve the situation somewhat by using the non-blocking > pqcomm functions in a few select places. E.g. if elog.c's > send_message_to_frontend() sent its message via a new pq_endmessage_noblock() > (which'd use the existing pq_putmessage_noblock()) and used > pq_flush_if_writable() instead of pq_flush(), we'd a) not block sending to the > client before AbortCurrentTransaction(), b) able to queue further error > messages safely. pq_flush_if_writable() could succeed in sending only part of the data, so I don't see how this works. -- Robert Haas EDB: http://www.enterprisedb.com