On Thursday 07 January 2010 22:28:46 Tom Lane wrote: > 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. Yes.
> 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. Well a session which is usable after a transaction abort is quite sensible - quite some software I know handles a failing transaction much more gracefully than a session abort (e.g. because it has to deal with serialization failures and such anyway). So making it cought by fewer places and degrading to FATAL sound sensible and relatively easy to me. Unless somebody disagrees I will give it a shot. @Simon: Could you possibly push your current HS state to the git repo? That would make it easier to see whats already applied and such. That would be really nice. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
