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

Robert Haas wrote:
> On Thu, Mar 19, 2015 at 10:23 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> > 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?

I don't understand why aren't interrupts held until after the commit is
done -- including across the mentioned ereports.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services