Re: SIGHUP not received by custom bgworkers if postmaster is notified
От | Alvaro Herrera |
---|---|
Тема | Re: SIGHUP not received by custom bgworkers if postmaster is notified |
Дата | |
Msg-id | 20130321151530.GA3685@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: SIGHUP not received by custom bgworkers if postmaster is notified (Euler Taveira <euler@timbira.com>) |
Ответы |
Re: SIGHUP not received by custom bgworkers if postmaster
is notified
|
Список | pgsql-hackers |
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. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: