Re: "cancelling statement due to user request error" occurs but the transaction has committed.

On Thu, Mar 19, 2015 at 10:23 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Thu, Mar 19, 2015 at 07:54:02AM -0400, Robert Haas wrote:
>> On Wed, Mar 18, 2015 at 10:56 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> > I have researched this issue originally reported in June of 2014 and
>> > implemented a patch to ignore cancel while we are completing a commit.
>> > I am not clear if this is the proper place for this code, though a
>> > disable_timeout() call on the line above suggests I am close. :-)
>>
>> This would also disable cancel interrupts while running AFTER
>> triggers, which seems almost certain to be wrong. TBH, I'm not sure
>> why the existing HOLD_INTERRUPTS() in CommitTransaction() isn't
>> already preventing this problem. Did you investigate that at all?
>
> Yes, the situation is complex, and was suggested by the original poster.
> The issue with CommitTransaction() is that it only _holds_ the signal
> --- it doesn't clear it. Now, since there are very few
> CHECK_FOR_INTERRUPTS() calls in the typical commit process flow, the
> signal is normally erased. However, if log_duration or
> log_min_duration_statement are set, they call ereport, which calls
> errfinish(), which has a call to CHECK_FOR_INTERRUPTS().
>
> First attached patch is more surgical and clears a possible cancel
> request before we report the query duration in the logs --- this doesn't
> affect any after triggers that might include CHECK_FOR_INTERRUPTS()
> calls we want to honor.
>
> Another approach would be to have CommitTransaction() clear any pending
> cancel before it calls RESUME_INTERRUPTS(). The second attached patch
> takes that approach, and also works.

So, either way, what happens if the query cancel shows up just an
instant after you clear the flag?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company