On 01/07/10 22:37, Andres Freund wrote:
> On Thursday 07 January 2010 22:28:46 Tom Lane wrote:
>> Andres Freund<andres@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.
Alternatively the current state is available at:
http://git.postgresql.org/gitweb?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/hs-query-cancel
Its a bit raw around the edges, but I wanted to get some feedback...
Andres
