On 2021/08/25 2:30, Robert Haas wrote:
> Hmm, maybe you're right. What about pg_cancel_backend()?
I was thinking that it's valid even if secure_write() doesn't react to
pg_cancel_backend() because it's basically called outside transaction block,
i.e., there is no longer transaction to cancel in that case. But there can be
some cases where secure_write() is called inside transaction block,
for example, when the query generates NOTICE message. In these cases,
secure_write() might need to react to the cancel request.
BTW, when an error happens, I found that a backend calls EmitErrorReport()
to report an error to a client, and then calls AbortCurrentTransaction()
to abort the transaction. If secure_write() called by EmitErrorReport()
gets stuck, a backend gets stuck inside transaction block and the locks
keep being held unnecessarily. Isn't this problematic? Can we change
the order of them?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
