Can a background worker exist without shared memory access for EXEC_BACKEND cases? - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Can a background worker exist without shared memory access for EXEC_BACKEND cases?
Date
Msg-id CALj2ACWrojZiMKVa_YOynZ6WYEDL9sRLBaqU6uNv2H+PZNJtKA@mail.gmail.com
Whole thread Raw
Responses Re: Can a background worker exist without shared memory access for EXEC_BACKEND cases?  (Robert Haas <robertmhaas@gmail.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Dmitry Markman
Date:
Subject: Re: windows config.pl question
Next
From: vignesh C
Date:
Subject: Re: Parallel copy