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(at)zim(dot)biz