Thread-safe signals

Someone mentioned a while ago that the signal handlers might not need to
be run on the main thread, making much of this issue moot.  I did some
checking on this and it looks like that might be the case.

We know we have the ability to receive signals on a separate thread and
respond to them instantly.. I believe this is sufficient for postmaster.

In the agent, some of the handlers don't do much:

quickdie
    writes error message, calls exit(1)

pgstat_die
    exit(1)

authdie
    exit(0)

SigHupHandler
    got_SIGHUP = true;

These are the handlers I found that look like they could be significant:

die
    This is postgres receiving an abort request from postmaster.
    Aborts transaction and quits as soon as possible.
    Does this via:
        InterruptPending = true;
        ProcDiePending = true;
        ...
        LockWaitCancel();
        ...

StatementCancelHandler
    Query-cancel signal from postmaster: abort current transaction
    at soonest convenient time.  Sets the QueryCancelPending and
    InterruptPending flags, calls LockWaitCancel if it seems safe
    (ImmediateInterruptOK, CritSectionCount==0,
InterruptHoldoffCount==0)

handle_sig_alarm
    Calls CheckDeadLock and CheckStatementTimeout

Async_NotifyHandler
    Calls ProcessIncomingNotify if it thinks it's safe to do so,
    otherwise lets it happen later.  What would be the implication
of
    letting it happen later?

handle_sigint
    sets cancel_pressed, calls PQrequestCancel which looks like
    it would be safe from a separate thread

If LockWaitCancel, CheckDeadLock, CheckStatementTimeout, and
ProcessIncomingNotify would be thread-safe (or could be deferred until
the main thread was done with the statement it's working on), then
the whole signal problem goes away.  Anyone familiar enough with these
to say?

--
Steve Tibbett
stibbett@zim.biz