On 2018-06-08 14:41:41 -0400, Tom Lane wrote: > Andres Freund <and...@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
