Re: Trapping QUERY_CANCELED: yes, no, maybe?

You are asking if a funciton itself might want to set query cancel and
catch the cancel and do something else? For 7.5 I would be happy just
canceling the entire thing.

---------------------------------------------------------------------------

Tom Lane wrote:
> Now that it is possible for plpgsql functions (and, no doubt, soon
> others) to trap errors, I think we need a little bit of discussion
> about what kind of restrictions should be put on trapping the
> QUERY_CANCELED error. If we treat QUERY_CANCELED as an absolutely
> ordinary error, it would be fairly easy for a carelessly written
> function to disable the backend from responding to ^C or
> statement_timeout --- it need only catch the error and keep on
> processing. On the other hand, it's not impossible to envision
> scenarios where you'd like to be able to catch QUERY_CANCELED.
> I can see people using that ability in combination with
> statement_timeout, in particular.
>
> The compromise that I put into plpgsql for the moment works like this:
>
> 1. EXCEPTION WHEN OTHERS THEN matches all error types *except*
> QUERY_CANCELED; thus you cannot accidentally catch that error. (When
> the EXCEPTION clause does not match the error type, the error just
> propagates outward, so QUERY_CANCELED will always force control back
> to the idle loop.)
>
> 2. But you can explicitly say EXCEPTION WHEN QUERY_CANCELED THEN
> if you really want to catch it.
>
> I can see that point #2 might be controversial, and that some might
> feel that QUERY_CANCELED should be untrappable, period. Does anyone
> want to argue for that? Does anyone think #1 is a bad idea?
>
> There is also an implementation-level issue, which is whether we should
> rely on the PLs' individual error handlers (which are mostly yet to be
> written) to enforce such policies consistently. As long as
> QUERY_CANCELED is the only special case, things aren't too bad, but
> if there's any prospect of having more special cases it could get messy.
> I thought about inventing a new elevel category, but really that does
> not help much, since we'd still be dependent on the error handlers to be
> cooperative. (We can't not run the handlers, since there is very likely
> state that they *must* undo before losing control.) Anyone see a
> cleaner approach?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073