Peter Geoghegan <pg@heroku.com> writes:
> On Thu, May 29, 2014 at 1:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Not throw the error. (If we did, it'd turn into a PANIC, which doesn't
>> seem like what we want.)
> Of course, but it isn't obvious to me that that isn't what we'd want,
> if the alternative is definitely that we'd be stuck in an infinite
> uninterruptible loop (I guess we couldn't just avoid throwing the
> error, thereby risking proceeding without locks -- and so I guess we
> can basically do nothing like this in critical sections). Now, that
> probably isn't the actual choice that we must face, but it also isn't
> obvious to me how you can do better than not throwing the error (and
> doing nothing extra) when in a critical section. That was the intent
> of my original question.
I don't feel a need for special behavior for this inside critical
sections; a critical section that lasts long enough for query cancel
response to be problematic is probably already broken by design.
The other case of InterruptHoldoffCount being too high might be more
relevant. I have not gone around and looked at retail uses of
HOLD_INTERRUPTS to see whether there are any that might be holding counts
for long periods. But I have checked that for the case in spgdoinsert,
the only thing staying ProcessInterrupts' hand is the holdoff count
associated with the buffer lock on the current index page.
regards, tom lane