Re: Dependency between bgw_notify_pid and bgw_flags

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

On Mon, Jun 8, 2015 at 1:51 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> 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?

Well, it sounds like we at least need to think about making it
consistently depend on shmem-access rather than database-connection.
I'm less sure what to do with workers that have not even got shmem
access.

--
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 Fujii Masao 2015-06-08 18:04:45 Re: Memory leak with XLogFileCopy since de768844 (WAL file with .partial)
Previous Message Bruce Momjian 2015-06-08 17:51:47 Re: Restore-reliability mode