| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Naoya Anzai <anzai-naoya(at)mxu(dot)nes(dot)nec(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Akio Iwaasa <iwaasa(at)mxs(dot)nes(dot)nec(dot)co(dot)jp> |
| Subject: | Re: "cancelling statement due to user request error" occurs but the transaction has committed. |
| Date: | 2015-03-19 22:55:16 |
| Message-ID: | 20150319225516.GB20462@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 19, 2015 at 04:36:38PM -0400, Robert Haas wrote:
> On Thu, Mar 19, 2015 at 10:23 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > 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?
Oh, good point. This version handles that case addressing only the
log_duration* block.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
| Attachment | Content-Type | Size |
|---|---|---|
| cancel4.diff | text/x-diff | 1.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2015-03-19 23:01:32 | Re: proposal: doc: simplify examples of dynamic SQL |
| Previous Message | David Christensen | 2015-03-19 22:41:02 | [PATCH] Add two-arg for of current_setting(NAME, FALLBACK) |