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

On Thu, Mar 19, 2015 at 08:43:52PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > On Thu, Mar 19, 2015 at 06:59:20PM -0300, Alvaro Herrera wrote:
> >> I don't understand why aren't interrupts held until after the commit is
> >> done -- including across the mentioned ereports.
>
> > Uh, I think Robert was thinking of pre-commit triggers at the top of
> > CommitTransaction() that might take a long time and we might want to
> > cancel.
>
> Yeah, that's a good point. So really the only way to make this work as
> requested is to have some cooperation between xact.c and postgres.c,
> so that the hold taken midway through CommitTransaction is kept until
> we reach the idle point.
>
> The attached is only very lightly tested but shows what we probably
> would need for this. It's a bit messy in that the API for
> CommitTransactionCommand leaves it unspecified whether interrupts are
> held at exit; I'm not sure if it's useful or feasible to be more precise.

Oh, I see what you are saying, and why a global variable will not work.
I thought all paths reset the cancel state when the returned from a
commit, but it seems there are many places that don't do reset, so you
have to pass a flag down into CommitTransaction() to control that ---
makes sense.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +