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

From Alvaro Herrera
Subject Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Date
Msg-id 202108021934.h5rnwl4rnfbp@alvherre.pgsql
Whole thread Raw
In response to Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS  ("Andres Freund" <andres@anarazel.de>)
Responses Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 2021-Aug-02, Andres Freund wrote:

> On Mon, Aug 2, 2021, at 12:12, Alvaro Herrera wrote:

> > 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).

Ah, that makes sense.  That doesn't sound super fragile, but it is odd
and it's probably a good argument for removing the feature, particularly
since nobody seems to be using it.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Ninguna manada de bestias tiene una voz tan horrible como la humana" (Orual)



pgsql-hackers by date:

Previous
From: "Andres Freund"
Date:
Subject: Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Next
From: Robert Haas
Date:
Subject: Re: Make relfile tombstone files conditional on WAL level