Skip site navigation (1) Skip section navigation (2)

Re: pgsql: Fix (some of the) breakage introduced into query-cancel

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Fix (some of the) breakage introduced into query-cancel
Date: 2010-01-08 02:51:24
Message-ID: 24830.1262919084@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committers
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Thu, 2010-01-07 at 16:29 +0000, Tom Lane wrote:
>> Instead of that, undo the original optimizations that threw away
>> QueryCancelPending anytime we were starting or finishing a command
>> read, and instead discard the cancel request within ProcessInterrupts
>> if we find that there is no HS reason for forcing a cancel and we are
>> DoingCommandRead.

> Is there a reason why we are calling DisableNotifyInterrupt() and
> DisableCatchupInterrupt() before we call ProcessInterrupts() and again
> within it?

Different purposes.  ProcessInterrupts is called from a lot of places
and should not assume the status of those flags --- in particular, if it
is called directly from the signal handler while we are waiting for a
command, those disables are needed because the interrupts are active.
The call site you are probably looking at is where we are exiting the
active-command-read state, and we want to disable the interrupts before
beginning active processing, whether or not there is any cancel interrupt
waiting.

			regards, tom lane

In response to

pgsql-committers by date

Next:From: User KasaharaDate: 2010-01-08 08:30:28
Subject: pgstatsinfo - pg_statsinfo: New Directory
Previous:From: Tom LaneDate: 2010-01-08 02:44:00
Subject: pgsql: Fix oversight in EvalPlanQualFetch: after failing to lock a tuple

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group