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
signature.asc
Description: PGP signature