On Fri, Mar 22, 2013 at 12:15 AM, Alvaro Herrera <alvhe...@2ndquadrant.com>wrote:
> Euler Taveira escribió: > > On 21-03-2013 05:06, Michael Paquier wrote: > > > While playing with custom background workers, I noticed that > postmaster does > > > not notify its registered bgworkers if it receives SIGHUP, > > > so you have to send a SIGHUP directly to the bgworker process to > notify it. > > > Signal handling is correctly done for SIGQUIT and SIGTERM for shutdown > only. > > > Attached is a patch fixing that, I simply added a call to > > > SignalUnconnectedWorkers in SIGHUP_handler:postmaster.c. > > > > > Per this discussion [1], it seems it is as is by design. AFAICS > controlling > > when change configuration parameters is a feature not a bug. Alvaro said > that > > will include SIGHUP handle in worker_spi (see [2] for how to process > > configurantion file). > > They are opposite ends of the problem. Worker code needs a SIGHUP > signal handler, whatever that is (most likely something that causes the > configuration to be reread), which is what Guillaume's patch is about; > but postmaster needs to *send* a SIGHUP to its bgworker children, which > is what Michael is on about. Currently postmaster signals children that > are connected to shmem, but it's not considering those that aren't > connected. > > At least that's how I understand the issue at hand, without actually > looking deeper into it. > Yes, that's exactly the problem. And I believe that the postmaster should also notify its registered bgworkers if it receives a SIGHUP as it does for its other backends. Have a look at the 1-line patch I sent to see how I fixed that... -- Michael
