Re: SIGHUP not received by custom bgworkers if postmaster is notified - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: SIGHUP not received by custom bgworkers if postmaster is notified
Date
Msg-id CAB7nPqTfF+725thAdMQAZgOLDYCnj15qRZQ9_kKSjQWYx3ua2Q@mail.gmail.com
Whole thread Raw
In response to Re: SIGHUP not received by custom bgworkers if postmaster is notified  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: SIGHUP not received by custom bgworkers if postmaster is notified  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers


On Fri, Mar 22, 2013 at 12:15 AM, Alvaro Herrera <alvherre@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

pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Single-argument variant for array_length and friends?
Next
From: Alvaro Herrera
Date:
Subject: Re: autovacuum not prioritising for-wraparound tables