Re: Interrupting long external library calls

On May26, 2012, at 12:40 , Simon Riggs wrote:
> On 25 May 2012 17:34, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I assume that the geos::util::Interrupt::request() call sets a flag
>> somewhere that's going to be periodically checked in long-running
>> loops. Would it be possible for the periodic checks to include a
>> provision for a callback into Postgres-specific glue code, wherein
>> you could test the same flags CHECK_FOR_INTERRUPTS does? A similar
>> approach might then be usable in other contexts, and it seems safer
>> to me than messing with a host environment's signal handling.
>
> Can we do that as a macro, e.g.
>
> POSTGRES_LIBRARY_INTERRUPT_CHECK()
>
> Otherwise the fix to this problem may be worse - faulty interrupt
> handlers are worse than none at all.

As it stands, ProcessInterrupts() sometimes returns instead of
ereport()ing even if InterruptPending is set, interrupts aren't
held off, and the code isn't in a critical section. That happens if
QueryCancelPending (or however that's called) gets reset after a
SIGINT arrived but before CHECK_FOR_INTERRUPTS() is called. Or at
least that is how I interpret the comment at the bottom of that
function...

We could thus easily provide POSTGRES_LIBRARY_INTERRUPT_CHECK() if
we're content with the (slim, probably) chance of false positives.

Or we'd need to refactor things in a way that allows the hypothetical
POSTGRES_LIBRARY_INTERRUPT_CHECK() to re-use the tests in
ProcessInterrupts(), but without modifying any of the flags.

best regards,
Florian Pflug