Re: bgworker sigusr1 handler

On Wed, Apr 10, 2013 at 12:15 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> Just for fun, I implemented a toy background worker tonight using the
> new bgworker framework. Generally, it went well, and I'm pleased with
> the design of the new facility. However, I did notice one oddity. I
> initialized the worker flags like this:
>
> worker.bgw_flags = BGWORKER_SHMEM_ACCESS;
>
> And... latches didn't work. It turns out that if you request database
> access, then the SIGUSR1 handler is set to procsignal_sigusr1_handler,
> which is fine. But if you don't, it gets set to SIG_IGN. And the
> result of *that* is that if someone sets a latch for which the
> background process is waiting, the background process fails to notice.
>
> Now, once you understand what's going on here, it's not hard to work
> around. But it seems to me that it would be a saner default to set
> the signal handler to something like the bgwriter handler, which just
> calls latch_sigusr1_handler.
>

There is currently a bug with bgworkers and SIGHUP. If postmaster receives
a SIGHUP, it does not notify its registered bgworkers:
http://www.postgresql.org/message-id/CAB7nPqQ-ccL9Q7wxpWNaG5Zs-hMLh_ayQb=rM2=+PXtWd+8ogw@mail.gmail.com

You can have a try with the example I provided, then try to reload
parameters with "pg_ctl reload" and you will notice that bgworkers do not
process SIGHUP as a normal backend would do.
--
Michael