Can a background worker exist without shared memory access for EXEC_BACKEND cases?

Поиск
Список
Период
Сортировка
От Bharath Rupireddy
Тема Can a background worker exist without shared memory access for EXEC_BACKEND cases?
Дата
Msg-id CALj2ACWrojZiMKVa_YOynZ6WYEDL9sRLBaqU6uNv2H+PZNJtKA@mail.gmail.com
обсуждение исходный текст
Ответы Re: Can a background worker exist without shared memory access for EXEC_BACKEND cases?  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Hi,

I tried to implement a static background(bg) worker without shared
memory access (BGWORKER_SHMEM_ACCESS), it worked fine on Linux machine
where EXEC_BACKEND is not defined(thanks to the fork() implementation
which does great job to get the global state from the
postmaster(parent) to bg worker(child)).

However, the problem arised, when I switched to EXEC_BACKEND mode, it
seems it doesn't. I digged a bit and the following is my analysis: for
EXEC_BACKEND cases, (say on Windows platforms where fork() doesn't
exist) the way postmaster creates a background worker is entirely
different. It is done through SubPostmasterMain and the global state
from the postmaster is shared with the background worker via shared
memory. MyLatch variable also gets created in shared mode. And having
no shared memory access for the worker for EXEC_BACKEND cases(in
StartBackgroundWorker, the shared memory segments get detached), the
worker fails to receive all the global state from the postmaster.
Looks like the background worker needs to have the
BGWORKER_SHMEM_ACCESS flag while registering for EXEC_BACKEND cases.

Please feel free to correct me if I miss anything here.

If the above analysis looks fine, then please find a patch that adds
some info in bgworker.sgml and bgworker.h.

Thoughts?

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dmitry Markman
Дата:
Сообщение: Re: windows config.pl question
Следующее
От: vignesh C
Дата:
Сообщение: Re: Parallel copy