Comment 4 for bug 548612

To Andrew.

libpq blocking sigpipe will render timers and interrupt-thread (targeting that thread) ineffective. One possible solution is to ignore sigpipe, use a different signal for interrupt-thread and ((remove sigpipe from the deferrable set) or (remove the check_deferrables_unblocked call)).

When choosing another signal instead of sigpipe one must consider what this commit message explains:

    1.0.26.7: use a signal for SIG_STOP_FOR_GC > SIGSEGV on Linux

    On Linux a signal generated by pthread_kill() with a signum that's
    lower than SIGSEGV can be delivered before a synchronously triggered
    SIGSEGV. This means that the sigsegv handler will be invoked with its
    context pointing to the handler for the signal that pthread_kill()
    sent. It's not really specific to SIGSEGV, it's the same for any
    synchronously generated signal.

    To work around this, we must never pthread_kill() with a signal with a
    lower signum than any of the synchronously triggered signals that we
    use: SIGTRAP, SIGSEGV, etc. In practice, currently we only send
    SIGPIPE to indicate that the thread interruption queue may need to be
    looked at and SIG_STOP_FOR_GC that's defined as SIGUSR1 currently.

    With SIGUSR1 being 10 and SIGSEGV 11 this can make
    handle_guard_page_triggered lose badly if GC wants to stop the thread
    at the same time. So let's use SIGUSR2 instead that's 12. Do the same
    on other OSes they may have same bug.

    See thread "Signal delivery order" from 2009-03-14 on
    <email address hidden>:

    http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/6773ac3dcb867da3#