On 2018-06-08 14:41:41 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2018-06-08 18:08:14 +0000, Peter Da Silva wrote:
> >> There is a C-level variable QueryCancelPending that can be used to
> >> monitor for this case, but it’s not visible at the pl/tcl scripting
> >> level. This is a simple new command that returns the current state of
> >> this variable to Tcl.
>
> > I'm not terribly opposed to this, but I wonder if the much more
> > pragmatic solution is to just occasionally call a database function that
> > checks this? You could just run SELECT 1 occasionally :/
>
> That would be quite expensive for the purpose, surely.
Sure, but it works today...
Either way, I'm not convinced that handling query cancels in isolation
is really the right thing. I think pretty much all forms of interrupt
would need to be processed, not just cancels. It's imo at least as
important to process session termination (including recovery conflicts),
and catchup interrupts. I think we largely require that the PLs handle
exceptions anyway, so just having a 'pg_process_interrupts()' function
that then is wrapped by the individual PLs would make sense imo.
Greetings,
Andres Freund
