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
