Is *that* why debugging backend startup is so hard!?

I just spent a rather frustrating hour trying to debug a backend startup
failure --- and getting nowhere because I couldn't catch the failure in
a debugger, or even step to where I thought it might be. I've seen this
sort of difficulty before, and always had to resort to expedients like
putting in printf's. But tonight I finally realized what the problem is.

The early stages of startup are run under signal mask BlockSig, which we
initialize to include *EVERY SIGNAL* (except SIGUSR1 for some reason).
In particular SIGTRAP is blocked, which prevents debugger breakpoints
from working. Even sillier, normally-fatal signals like SIGSEGV are
blocked. I now know by observation that HPUX, at least, takes this
literally: for example, if you've blocked SEGV you don't hear about bus
errors, you just keep going. Possibly rather slowly, if every attempted
instruction execution causes the hardware to fault to the kernel, but
by golly the system will keep trying to run your code.

Needless to say I find this braindead in the extreme. Will anyone
object if I change the signal masks so that we never ever block
SIGABRT, SIGILL, SIGSEGV, SIGBUS, SIGTRAP, SIGCONT, SIGSYS? Any
other candidates? Are there any systems that do not define all
of these signal names?

BTW, once I turned this silliness off, I was able to home in on
my bug within minutes...

regards, tom lane

PS: The postmaster spends most of its time running under BlockSig too.
Good thing we haven't had many postmaster bugs lately.