Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Дата
Msg-id 20210802070142.7if4iclbps47hkah@alap3.anarazel.de
обсуждение исходный текст
Ответ на EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Следующее
От: Peter Smith
Дата:
Сообщение: Re: [HACKERS] logical decoding of two-phase transactions