Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Andres Freund <andres(at)anarazel(dot)de>
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:34:07
Message-ID: 202108021934.h5rnwl4rnfbp@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-08-02 20:03:31 Re: Make relfile tombstone files conditional on WAL level
Previous Message Andres Freund 2021-08-02 19:17:28 Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS