From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Joachim Wieland <joe(at)mcknight(dot)de>, Kris Jurka <books(at)ejurka(dot)com> |
Subject: | Re: Hot Standy introduced problem with query cancel behavior |
Date: | 2010-01-12 05:40:02 |
Message-ID: | 4B4C0B32.3080504@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/07/10 22:37, Andres Freund wrote:
> On Thursday 07 January 2010 22:28:46 Tom Lane wrote:
>> Andres Freund<andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2010-01-12 07:12:50 | Re: damage control mode |
Previous Message | Andres Freund | 2010-01-12 05:30:17 | Re: Hot Standy introduced problem with query cancel behavior |