Re: Can a background worker exist without shared memory access for EXEC_BACKEND cases?

Thank you Robert for the comments.

On Mon, Aug 3, 2020 at 9:19 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Fri, Jul 31, 2020 at 11:13 PM Bharath Rupireddy
> <bharath.rupireddyforpostgres@gmail.com> wrote:
> > memory. MyLatch variable also gets created in shared mode. And having
> > no shared memory access for the worker for EXEC_BACKEND cases(in
> > StartBackgroundWorker, the shared memory segments get detached), the
> > worker fails to receive all the global state from the postmaster.
>
> What exactly do you mean by "all the global state"?
>

My intention was exactly to refer to the variables specified in
BackendParameters struct.

>
> It's certainly true that if you declare some random static variable
> and initialize it in the postmaster, and you don't take any special
> precautions to propagate that into workers, then on an EXEC_BACKEND
> build, it won't be set in the workers. That's why, for example, most
> of the *ShmemInit() functions are written like this:
>
>         TwoPhaseState = ShmemInitStruct("Prepared Transaction Table",
>
>  TwoPhaseShmemSize(),
>                                                                         &found);
>         if (!IsUnderPostmaster)
> ...initialize the data structure...
>         else
>                 Assert(found);
>
> The assignment to TwoPhaseState is unconditional, because in an
> EXEC_BACKEND build that's going to be done in every process, and
> otherwise the variable won't be set. But the initialization of the
> shared data structure happens conditionally, because that needs to be
> done only once.
>
> See also the BackendParameters stuff, which arranges to pass down a
> bunch of things to exec'd backends.
>

I could get these points earlier in my initial analysis. In fact, I
could figure out the flow on Windows, how these parameters are shared
using a shared file(CreateFileMapping(), MapViewOfFile()), and the
shared file name being passed as an argv[2] to the child process, and
the way child process uses this file name to read the backend
parameters in read_backend_variables().

>
> I am not necessarily opposed to trying to clarify the documentation
> and/or comments here, but "global state" is a fuzzy term that doesn't
> really mean anything to me.
>

How about having "backend parameters from the postmaster....." as is
being referred to in the internal_forkexec() function comments? I
rephrased the comments adding "backend parameters.." and removing
"global state". Please find the v2 patch attached.

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com