From f44eb86d221bd6215f85a940610e67e7e9af3524 Mon Sep 17 00:00:00 2001 From: Bharath Rupireddy Date: Tue, 4 Aug 2020 09:45:01 +0530 Subject: [PATCH v2] Background worker shared memory access for EXEC_BACKEND cases If the background worker doesn't need shared memory access, on non-EXEC_BACKEND cases (such as Unix/Linux platforms) it is fine, since the worker gets all the backend parameters(See BackendParameters struct) required from the postmaster by the way the fork() is implemented. However, for EXEC_BACKEND cases, (say on Windows platforms where fork() doesn't exist) the way postmaster creates a background worker is different. It is done through SubPostmasterMain and the backend parameters from the postmaster are shared with the background worker via shared memory. 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 the backend parameters from the postmaster. Hence the background worker needs to have BGWORKER_SHMEM_ACCESS flag while registering for EXEC_BACKEND cases. --- doc/src/sgml/bgworker.sgml | 14 +++++++++++++- src/include/postmaster/bgworker.h | 15 +++++++++++++++ 2 files changed, 28 insertions(+), 1 deletion(-) diff --git a/doc/src/sgml/bgworker.sgml b/doc/src/sgml/bgworker.sgml index 6e1cf121de..483d599e55 100644 --- a/doc/src/sgml/bgworker.sgml +++ b/doc/src/sgml/bgworker.sgml @@ -89,7 +89,19 @@ typedef struct BackgroundWorker cannot access any of PostgreSQL's shared data structures, such as heavyweight or lightweight locks, shared buffers, or any custom data structures which the worker itself may - wish to create and use. + wish to create and use. If the background worker doesn't need shared + memory access, on non-EXEC_BACKEND cases (such as Unix/Linux platforms) + it is fine, since the worker gets all the backend parameters(See + BackendParameters structure) required from the + postmaster by the way the fork() is implemented. However, for EXEC_BACKEND + cases, (say on Windows platforms where fork() doesn't exist) the way postmaster + creates a background worker is different. It is done through SubPostmasterMain + and the backend parameters from the postmaster are shared with the background + worker via shared memory. 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 the backend parameters from the + postmaster. Hence the background worker needs to have BGWORKER_SHMEM_ACCESS + flag while registering for EXEC_BACKEND cases. diff --git a/src/include/postmaster/bgworker.h b/src/include/postmaster/bgworker.h index 4c6ebaa41b..6ebb00ceda 100644 --- a/src/include/postmaster/bgworker.h +++ b/src/include/postmaster/bgworker.h @@ -51,6 +51,21 @@ */ #define BGWORKER_SHMEM_ACCESS 0x0001 +/* + * If the background worker doesn't need shared memory access, on non-EXEC_BACKEND + * cases (such as Unix/Linux platforms) it is fine, since the worker gets all the + * backend parameters(See BackendParameters struct) required from the postmaster + * by the way the fork() is implemented. However, for EXEC_BACKEND cases, (say on + * Windows platforms where fork() doesn't exist) the way postmaster creates a + * background worker is different. It is done through SubPostmasterMain and the + * backend parameters from the postmaster are shared with the background worker via + * shared memory. 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 the backend parameters from the postmaster. Hence the + * background worker needs to have BGWORKER_SHMEM_ACCESS flag while registering for + * EXEC_BACKEND cases. + */ + /* * This flag means the bgworker requires a database connection. The connection * is not established automatically; the worker must establish it later. -- 2.25.1