Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS - Mailing list pgsql-hackers

From Andres Freund
Subject Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Date
Msg-id 2f2fc63f-7d21-4db6-abce-18610a9497fb@www.fastmail.com
Whole thread Raw
In response to Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
Hi,

On Mon, Aug 2, 2021, at 12:12, Alvaro Herrera wrote:
> On 2021-Aug-02, Andres Freund wrote:
> > I do think there's some potential gains in simplicity and robustness
> > that are made mildly harder by a subprocess that first attaches and
> > detaches from shm (it's the only case where we can't easily unify the
> > place InitProcess() is called between EB and ! EB right now). There's
> > several ways that could be tackled. Removing the need to have that if
> > obviously one of them.
> 
> Hmm, I don't remember that an shmem-unconnected bgworker first connected
> to it and then let go.  It seems weird to do it that way.  My intention,
> as far as I recall, is that they would just never connect to shmem,
> period.

They currently do for EXEC_BACKEND. See SubPostmasterMain(). There the definition of the worker is passed via shared
memory.So it does the full reattach thing, which requires lwlock, which requires PGPROC. We could get away without that
bypassing more through the variables file (either the worker definition or the address of the bgworker shmem piece).
 

Greetings,

Andres



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Next
From: Alvaro Herrera
Date:
Subject: Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS