Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Development <pgsql-hackers@postgresql.org>
Date: 2021-08-02T19:34:07Z
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)
Commits
-
Remove support for background workers without BGWORKER_SHMEM_ACCESS.
- 80a8f95b3bca 15.0 landed
-
Detach shared memory from bgworkers without shmem access.
- 4d155d8b08fe 9.4.0 cited