On 14 November 2017 at 13:09, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote:
>> *) Will pg_cancel_backend() cancel the currently executing statement >> or the procedure? (I guess probably the procedure but I'm curious) > > Same as the way it currently works. It will raise an exception, which > will travel up the stack and eventually issue an error or be caught. If > someone knows more specific concerns here I could look into it, but I > don't see any problem. > >> *) Will long running procedures be subject to statement timeout (and >> does it apply to the entire procedure)? > > See previous item. > >> Will they be able to control >> statement_timeout from within the procedure itself? > > The statement timeout alarm is set by the top-level execution loop, so > you can't change a statement timeout that is already in progress. But > you could change the GUC and commit it for the next top-level statement. > >> *) Will pg_stat_activity show the invoking CALL or the currently >> executing statement? I see a strong argument for showing both of >> these things. although I understand that's out of scope here. > > Not different from a function execution, i.e., top-level statement. Which is the "top-level statement"? The CALL or the currently executing statement within the proc? I think you mean former. For the first two answers above the answer was "currently executing statement", yet the third answer seems to be the procedure. So that is a slight discrepancy. ISTM we would like 1) a way to cancel execution of a procedure 2) a way to set a timeout to cancel execution of a procedure as well as 1) a way to cancel execution of a statement that is running within a procedure 2) a way to set a timeout to cancel execution of a statement in a procedure Visibility of what a routine is currently executing is the role of a debugger utility/API. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
