bgworker sigusr1 handler

Started by Robert Haasabout 13 years ago3 messageshackers
Jump to latest
#1Robert Haas
robertmhaas@gmail.com

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#2Michael Paquier
michael@paquier.xyz
In reply to: Robert Haas (#1)
Re: bgworker sigusr1 handler

On Wed, Apr 10, 2013 at 12:15 PM, Robert Haas <robertmhaas@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:
/messages/by-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

#3Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Robert Haas (#1)
Re: bgworker sigusr1 handler

Robert Haas escribió:

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.

Thanks.

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.

Sounds sensible -- done that way.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers