On Fri, May 04, 2018 at 12:47:09AM -0400, Mike Palmiotto wrote:
> I don't seem to have any problem catching the SIGHUP in my extension
> without > BackgroundWorkerUnblockSignals a la:
>
> pqsignal_sighup(SIGHUP, sighup_handler);
I am pretty sure you mean s/pqsignal_sighup/pqsignal/.
> static void
> sighup_handler(SIGNAL_ARGS)
> {
> <parse configs>
> }
Signal handlers should not do anything complicated, and should access
only variables of the type volatile sig_atomic_t. This is also in the
documentation here (see Writing Signal Handlers):
https://www.postgresql.org/docs/devel/static/source-conventions.html
> Perhaps the signal is already unblocked at this point. Unblocking signals
> first doesn't appear to have any affect. Am I missing something here?
>
> I noticed that 6e1dd27
> (https://github.com/postgres/postgres/commit/6e1dd2773eb60a6ab87b27b8d9391b756e904ac3)
> introduced a ConfigReloadPending flag that can be set by calling
> PostgresSigHupHandler inside the extension's handler, which seemingly allows
> things to work as they usually would, and then we can go on to do other config
> processing.
>
> Is this approach kosher, or is there another preferred route?
From the documentation of
https://www.postgresql.org/docs/devel/static/bgworker.html:
Signals are initially blocked when control reaches the background
worker's main function, and must be unblocked by it; this is to allow
the process to customize its signal handlers, if necessary. Signals can
be unblocked in the new process by calling
BackgroundWorkerUnblockSignals and blocked by calling
BackgroundWorkerBlockSignals.
I have for ages in one of my github repositories a small example of
bgworker which covers signal handling, located here:
https://github.com/michaelpq/pg_plugins/tree/master/hello_signal
If you quote the call to BackgroundWorkerUnblockSignals, you would see
that the SIGHUP is not received by the process, which is what the
documentation says, and what I would expect as well.
--
Michael
