Re: Dependency between bgw_notify_pid and bgw_flags - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Dependency between bgw_notify_pid and bgw_flags
Date
Msg-id CA+Tgmoa4WSO8wpWyVZqj7SOYG5_uTXmCGjNpVC7z35sxnxvqyQ@mail.gmail.com
Whole thread Raw
In response to Dependency between bgw_notify_pid and bgw_flags  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: Dependency between bgw_notify_pid and bgw_flags  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Thu, Jun 4, 2015 at 8:52 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
> Documentation here http://www.postgresql.org/docs/devel/static/bgworker.html
> does not indicate any relation between the fields bgw_notify_pid and
> bgw_flags of BackgroundWorker structure. But in one has to set
> BGWORKER_BACKEND_DATABASE_CONNECTION in order to use bgw_notify_pid feature.

The comments in maybe_start_bgworker make it fairly clear that this
was done intentionally, but they don't explain why:
                        * If not connected, we don't need a Backend
element, but we still                        * need a PMChildSlot.

But there's another comment elsewhere that says that the criteria is
shared-memory access, not database connection:
* Background workers that request shared memory access during registration are* in this list, too.

So at a minimum, the current situation is not self-consistent.

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
bylaunching "dead_end"* child processes, which will simply send the client an error message and* quit.  (We track these
inthe 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
whenwe 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
thesystem, 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?

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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Next
From: Robert Haas
Date:
Subject: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1