On Wed, Apr 10, 2013 at 12:15 PM, Robert Haas <robertmh...@gmail.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+8...@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
