Re: Process initialization labyrinth - Mailing list pgsql-hackers

From Mike Palmiotto
Subject Re: Process initialization labyrinth
Date
Msg-id CAMN686HDiCzbsgQ2zsTyJpwgFPs0WaMz40oFrbgMqsdbO4hpFw@mail.gmail.com
Whole thread Raw
In response to Process initialization labyrinth  (Andres Freund <andres@anarazel.de>)
Responses Re: Process initialization labyrinth  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Thu, Apr 1, 2021 at 8:22 PM Andres Freund <andres@anarazel.de> wrote:
> <snip>
> I have now worked around this by generous application of ugly, but I
> think we really need to do something about this mazy mess. There's just
> an insane amount of duplication, and it's too complicated to remember
> more than a few minutes.
>
> I really would like to not see things like
>
>         /*
>          * Create a per-backend PGPROC struct in shared memory, except in the
>          * EXEC_BACKEND case where this was done in SubPostmasterMain. We must do
>          * this before we can use LWLocks (and in the EXEC_BACKEND case we already
>          * had to do some stuff with LWLocks).
>          */
> #ifdef EXEC_BACKEND
>         if (!IsUnderPostmaster)
>                 InitProcess();
> #else
>         InitProcess();
> #endif
>
> Similarly, codeflow like bootstrap.c being involved in bog standard
> stuff like starting up wal writer etc, is just pointlessly
> confusing. Note that bootstrap itself does *not* go through
> AuxiliaryProcessMain(), and thus has yet another set of initialization
> needs.

I can't really speak to the initial points directly relating to
pgstat/shmem, but for the overall maze-like nature of the startup
code: is there any chance the startup centralization patchset would be
of any help here?
https://www.postgresql.org/message-id/flat/CAMN686FE0OdZKp9YPO=htC6LnA6aW4r-+jq=3Q5RAoFQgW8EtA@mail.gmail.com

I know you are at least vaguely aware of the efforts there, as you
reviewed the patchset. Figured I should at least bring it up in case
it seemed helpful, or an effort you'd like to re-invigorate.

Thanks,

--
Mike Palmiotto
https://crunchydata.com



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: policies with security definer option for allowing inline optimization
Next
From: Laurenz Albe
Date:
Subject: Re: documentation fix for SET ROLE