On May26, 2012, at 12:40 , Simon Riggs wrote: > On 25 May 2012 17:34, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
