Re: Are we accepting cancel interrupts too often? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Are we accepting cancel interrupts too often?
Date
Msg-id 200112311614.fBVGEXb26696@candle.pha.pa.us
Whole thread Raw
In response to Are we accepting cancel interrupts too often?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Presently, the RESUME_INTERRUPTS() and END_CRIT_SECTION() macros implicitly
> do a CHECK_FOR_INTERRUPTS(); that is, if a cancel request arrived during
> the interrupt-free section it will be serviced immediately upon exit
> from the section.
> 
> It strikes me that this is a really bad idea.  There are lots of places
> where we release one lock then acquire another, and are not expecting to
> lose control in between.  The original concept of the query-cancel
> facility was that we'd accept cancels only at *explicit*
> CHECK_FOR_INTERRUPTS points.  What we actually have at the moment is
> that cancels could be accepted in a very wide variety of places, and
> I don't believe we've considered the consequences at each such place.
> 
> I am inclined to remove the ProcessInterrupts calls from
> RESUME_INTERRUPTS and END_CRIT_SECTION.  Does anyone object?

I read the nice description of RESUME_INTERRUPTS at the top of
miscadmin.c and I agree that the idea of allowing a CHECK_FOR_INTERRUPTS
call is not the same as making the call.

I started to look at when this nice code was added to determine if this
was part of the original design or added later and found you wrote it
yourself, so I guess we don't have to ask anyone to make sure there
isn't something were are missing.

Looking at CHECK_FOR_INTERRUPTS calls, those are all in safe places,
while the RESUME_INTERRUPTS are not in obviously safe places, so I agree
with your suggested change.

---------------------------------------------------------------------------
Revision 1.77 / (download) - annotate - [select for diffs] , Sun Jan 14
05:08:16 2001 UTC (11 months, 2 weeks ago) by tgl
Changes since 1.76: +73 -36 lines
Diff to previous 1.76

Restructure backend SIGINT/SIGTERM handling so that 'die' interrupts
are treated more like 'cancel' interrupts: the signal handler sets a
flag that is examined at well-defined spots, rather than trying to cope
with an interrupt that might happen anywhere.  See pghackers discussion
of 1/12/01.



--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Kevin Xiao
Date:
Subject: Error: SET TRANSACTION ISOLATION LEVEL must be called before any query
Next
From: "Jeffrey W. Baker"
Date:
Subject: Re: LWLock contention: I think I understand the problem