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

From Tom Lane
Subject Are we accepting cancel interrupts too often?
Date
Msg-id 669.1009737965@sss.pgh.pa.us
Whole thread Raw
Responses Re: Are we accepting cancel interrupts too often?  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: My email is fixed
Next
From: Maarten.Boekhold@reuters.com
Date:
Subject: Re: contrib/dbase