Re: What (not) to do in signal handlers

Doug McNaught <doug(at)wireboard(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Hm. That's one way, but is it really any cleaner than our existing
>> technique? Since you still need to assume you can do a system call
>> in a signal handler, it doesn't seem like a real gain in
>> bulletproofness to me.

> Doing write() in a signal handler is safe; doing fprintf() (and
> friends) is not.

If we were calling the signal handlers from random places, then I'd
agree. But we're not: we use sigblock to ensure that signals are only
serviced at the place in the postmaster main loop where select() is
called. So there's no actual risk of reentrant use of non-reentrant
library functions.

Please recall that in practice the postmaster is extremely reliable.
The single bug we have seen with the signal handlers in recent releases
was the problem that they were clobbering errno, which was easily fixed
by saving/restoring errno. This same bug would have arisen (though at
such low probability we'd likely never have solved it) in a signal
handler that only invoked write(). So I find it difficult to buy the
argument that there's any net gain in robustness to be had here.

In short: this code isn't broken, and so I'm not convinced we should
"fix" it.

regards, tom lane