Robert Haas wrote: > On Thu, Mar 19, 2015 at 10:23 AM, Bruce Momjian <br...@momjian.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
