Andres Freund <and...@anarazel.de> writes:
> I did not want to suggest using Simons code there. Sorry for the brevity.
> should have read as "revert to old code and add two step killing (thats
> likely
> around 10 lines or so)".
> "two step killing" meaning that we signal ERROR for a few times and if
> nothing
> happens that we like, we signal FATAL.
> As the code already loops around signaling anyway that should be easy to
> implement.
Ah. This loop happens in the process that's trying to send the cancel
signal, correct, not the one that needs to respond to it? That sounds
fairly sane to me.
There are some things we could do to make it more likely that a cancel
of this type is accepted --- for instance, give it a distinct SQLSTATE
code that *can not* be trapped by plpgsql EXCEPTION blocks --- but there
is no practical way to guarantee it except elog(FATAL). I'm not
entirely convinced that an untrappable error would be a good thing
anyway; it's hard to argue that that's much better than a FATAL.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
