Re: Queries that should be canceled will get stuck on secure_write function

On Tue, Aug 24, 2021 at 9:58 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
> 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.

Yeah. I think we could also be sending tuple data.

> 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?

I think there might be problems with that, like perhaps the ErrorData
object can have pointers into the memory contexts that we'd be
destroying in AbortCurrentTransaction().

More generally, I think it's hopeless to try to improve the situation
very much by changing the place where secure_write() happens. It
happens in so many different places, and it is clearly not going to be
possible to make it so that in none of those places do we hold any
important server resources. Therefore I think the only solution is to
fix secure_write() itself ... and the trick is what to do there given
that we have to be very careful not to do anything that might try to
write another message while we are already in the middle of writing a
message.

--
Robert Haas
EDB: http://www.enterprisedb.com