Re: Review: Extra Daemons / bgworker - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Review: Extra Daemons / bgworker
Date
Msg-id 20121205214242.GG4673@alvh.no-ip.org
Whole thread Raw
In response to Re: Review: Extra Daemons / bgworker  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Review: Extra Daemons / bgworker
List pgsql-hackers
Andres Freund wrote:
> On 2012-12-05 12:09:58 -0300, Alvaro Herrera wrote:
> > Here's a first attempt at a new documentation chapter.  This goes in
> > part "Server Programming", just after the SPI chapter.
> >
> > I just noticed that worker_spi could use some more sample code, for
> > example auth_counter was getting its own LWLock and also its own shmem
> > area, which would be helpful to demonstrate I think.
>
> I am not exactly renowned for my english skills, but I have made a pass
> over the file made some slight changes and extended it in two places.

Thanks, I have applied it.

> I've also added a comment with a question that came to my mind when
> reading the docs...

>    <para>
>     <structfield>bgw_sighup</structfield> and <structfield>bgw_sigterm</> are
>     pointers to functions that will be installed as signal handlers for the new
> -   process.
> +   process. XXX: Can they be NULL?
>    </para>

Hm.  The code doesn't check, so what happens is probably a bug anyhow.
I don't know whether sigaction crashes in this case; its manpage doesn't
say.  I guess the right thing to do is have RegisterBackgroundWorker
check for a NULL sighandler, and set it to something standard if so (say
SIG_IGN for SIGHUP and maybe quickdie() or similar for SIGTERM).

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Dumping an Extension's Script
Next
From: Simon Riggs
Date:
Subject: Re: Review: Extra Daemons / bgworker