Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS

From: "Andres Freund" <andres(at)anarazel(dot)de>
To: "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Date: 2021-08-02 19:17:28
Message-ID: 2f2fc63f-7d21-4db6-abce-18610a9497fb@www.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 by passing more through the variables file (either the worker definition or the address of the bgworker shmem piece).

Greetings,

Andres

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2021-08-02 19:34:07 Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Previous Message Alvaro Herrera 2021-08-02 19:12:49 Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS