Re: PostmasterContext survives into parallel workers!?

Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2016-08-01 18:09:03 -0400, Robert Haas wrote:
> >> (Also vaguely on the list of things to clean up: can't we make it so
> >> that bgworkers aren't launched from inside a signal handler? Blech.)
>
> > Isn't pretty much everything on-demand below postmaster started from a
> > signal handler?
>
> I think it depends. As an example, maybe_start_bgworker is called
> from PostmasterMain, *and* from ServerLoop, *and* from reaper,
> *and* from sigusr1_handler. That's likely excessive, but it's what
> we've got at the moment.

As I recall, each of those calls correspond to some particular need;
keep in mind that bgworkers can request to be started at a few different
points: either right at postmaster start, or when consistent state is
reached on a standby, or when recovery is finished.
maybe_start_bgworker only starts one bgworker, and it also sets a flag
so that ServerLoop will call it another time if there are pending
workers for the same timing event. That explains the four calls to
maybe_start_bgworker, and as I recall removing any of these would break
some possible usage. And yes, I did put two of these in signal handlers
precisely because that is postmaster's longstanding practice.

(It's perhaps possible to remove the call from ServerLoop if you make
maybe_start_bgworker process all of them at once instead, but as I
recall we decided to do only one at a time so that ServerLoop had a
chance to run other control logic in between, just in case.)

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