Re: pgsql: Fix (some of the) breakage introduced into query-cancel
От | Tom Lane |
---|---|
Тема | Re: pgsql: Fix (some of the) breakage introduced into query-cancel |
Дата | |
Msg-id | 24830.1262919084@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Fix (some of the) breakage introduced into query-cancel (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-committers |
Simon Riggs <simon@2ndquadrant.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
В списке pgsql-committers по дате отправления: