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

From Andres Freund
Subject Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Date
Msg-id 20210802070142.7if4iclbps47hkah@alap3.anarazel.de
Whole thread Raw
In response to EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS  (Andres Freund <andres@anarazel.de>)
List 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Next
From: Peter Smith
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions