Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2021-08-02T07:01:42Z
Lists: pgsql-hackers
Hi, On 2021-08-01 23:51:16 -0700, Andres Freund wrote: > In practice this will lead pretty quickly to a segfault, because process exit > will run proc_exit callbacks, which in turn will try to do a ProcKill(). Or > logging dereferences MyProc, or ... > > It seems the above code block would need to at least do shmem_exit() before > the PGSharedMemoryDetach()? > I tested both the crash and that a shmem_exit() fixes it with an ugly hack in > regress.c. I don't really know how to write a good testcase for this, given > that the communication facilities of a unconnected bgworker are quite > limited... I guess the bgworker could create files or something :(. Hm. There may be another way: Because BackgroundWorkerEntry() does not actually need a lock, we could transport BackgroundWorkerData via backend_save_variables(). To make the connected case work, we'd of course continue to call CreateSharedMemoryAndSemaphores (and thus InitProcess()) for those. But that doesn't really seem better? Sure, it's nice to not need a pgproc entry unnecessarily, but it's not like unconnected bgworkers are commonly used and it does seem like it'd end up with more complicated code? Greetings, Andres Freund
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