Re: SIGHUP not received by custom bgworkers if postmaster is notified

On Fri, Mar 22, 2013 at 12:15 AM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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