Re: Proper way to reload config files in backend SIGHUP handler - Mailing list pgsql-hackers

From Mike Palmiotto
Subject Re: Proper way to reload config files in backend SIGHUP handler
Date
Msg-id 48518af6-53be-f7e7-7871-8a2899ec16d3@crunchydata.com
Whole thread Raw
In response to Re: Proper way to reload config files in backend SIGHUP handler  (Euler Taveira <euler@timbira.com.br>)
Responses Re: Proper way to reload config files in backend SIGHUP handler  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On 05/03/2018 08:43 PM, Euler Taveira wrote:
> 2018-05-03 19:25 GMT-03:00 Mike Palmiotto <mike.palmiotto@crunchydata.com>:
>> I am writing a PostgreSQL extension and need to reload certain
>> extension-managed files whenever the postmaster is reloaded/receives SIGHUP,
>> but cannot find anything that looks like a standard way to do that. Is there a
>> hook or recommended method or something else I am missing?
>>
> Signals are initially blocked in bgworker. You have to unblock them
> (see BackgroundWorkerUnblockSignals) to allow your extension to
> customize its signal handlers. See an example in worker_spi test
> module.

I don't seem to have any problem catching the SIGHUP in my extension without
BackgroundWorkerUnblockSignals a la:

----

pqsignal_sighup(SIGHUP, sighup_handler);
.
.
.
static void
sighup_handler(SIGNAL_ARGS)
{
  <parse configs>
}

----

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?

Thanks,

-- 
Mike Palmiotto
Software Engineer
Crunchy Data Solutions
https://crunchydata.com


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: ignore_system_indexes affects DROP SCHEMA ... CASCADE reportednumber of objects dropped
Next
From: Andrew Gierth
Date:
Subject: Re: ignore_system_indexes affects DROP SCHEMA ... CASCADE reported number of objects dropped