On Sat, May 26, 2012 at 01:24:26PM +0200, Florian Pflug wrote: > 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.
So back to this, shortly after discovering (sorry for ignorance, but I just don't care about programming in a black box environment) that windows doesn't support posix signals. If I understood correctly the CHECK_FOR_INTERRUPTS postgresql function does also take care of events dispatching within windows, so that if nothing calls that macro there's no way that a "pqsignal" handler would be invoked. Is that right ? In that case I can understand Tom's advice about providing a callback, and then I would only need to perform the "events flushing" part of from within the callback, and only for windows. Does it sound right ? --strk; -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers