Re: What (not) to do in signal handlers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I notice that the signal handlers in postmaster.c do quite a lot of work,
> much more than what they teach you in school they should do.

Yes, they're pretty ugly. However, we have not recently heard any
complaints suggesting problems with it. Since we block signals
everywhere except just around the select() for new input, there's not
really any risk of recursive resource use AFAICS.

> ISTM that most of these, esp. pmdie(), can be written more like the SIGHUP
> handler, i.e., set a global variable and evaluate right after the
> select().

I would love to see it done that way, *if* you can show me a way to
guarantee that the signal response will happen promptly. AFAIK there's
no portable way to ensure that we don't end up sitting and waiting for a
new client message before we get past the select(). If we could release
the signal mask just as an atomic part of the select operation, then
it'd work, but only some platforms support that. This has been
discussed before, look in the archives.

SIGHUP is okay because we don't really care whether the postmaster
rereads the config file right away or only when it's about to process a
new request, anyhow. But for other sorts of signals we need to be sure
that there can't be an indefinite delay before the signal is acted on.

regards, tom lane