Re: Dependency between bgw_notify_pid and bgw_flags

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Álvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Dependency between bgw_notify_pid and bgw_flags
Date: 2015-06-08 17:31:08
Message-ID: CA+Tgmoa4WSO8wpWyVZqj7SOYG5_uTXmCGjNpVC7z35sxnxvqyQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 4, 2015 at 8:52 AM, Ashutosh Bapat
<ashutosh(dot)bapat(at)enterprisedb(dot)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 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?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-06-08 17:33:17 Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Previous Message Alvaro Herrera 2015-06-08 17:23:32 Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1