Re: Dependency between bgw_notify_pid and bgw_flags

Robert Haas wrote:

> After studying this, I think it's a bug. See this comment:
>
> * Normal child backends can only be launched when we are in PM_RUN or
> * PM_HOT_STANDBY state. (We also allow launch of normal
> * child backends in PM_WAIT_BACKUP state, but only for superusers.)
> * In other states we handle connection requests by launching "dead_end"
> * child processes, which will simply send the client an error message and
> * quit. (We track these in the BackendList so that we can know when they
> * are all gone; this is important because they're still connected to shared
> * memory, and would interfere with an attempt to destroy the shmem segment,
> * possibly leading to SHMALL failure when we try to make a new one.)
> * In PM_WAIT_DEAD_END state we are waiting for all the dead_end children
> * to drain out of the system, and therefore stop accepting connection
> * requests at all until the last existing child has quit (which hopefully
> * will not be very long).
>
> That comment seems to imply that, at the very least, all backends with
> shared-memory access need to be part of BackendList. But really, I'm
> unclear why we'd ever want to exit without all background workers
> having shut down, so maybe they should all be in there. Isn't that
> sorta the point of this facility?
>
> Alvaro, any thoughts?

As I recall, my thinking was:

* anything connected to shmem that crashes could leave things in bad
state (for example locks improperly held), whereas things not connected
to shmem could crash without it being a problem for the rest of the
system and thus do not require a full restart cycle. This stuff is
detected with the PMChildSlot thingy; therefore all bgworkers with shmem
access should have one of these.

* I don't recall offhand what the criteria is for stuff to be in
postmaster's BackendList. According to the comment on top of struct
Backend, bgworkers connected to shmem should be on that list, even if
they did not have the BGWORKER_BACKEND_DATABASE_CONNECTION flag on
registration. So that would be a bug.

Does this help you any?

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