making bgworkers without shmem access actually not have shmem access - Mailing list pgsql-hackers

From Robert Haas
Subject making bgworkers without shmem access actually not have shmem access
Date
Msg-id CA+Tgmob1Ok2erRfVB-8Zj+nW5gFzBPrY5_dCk8a9xB2CbS-w8A@mail.gmail.com
Whole thread Raw
Responses Re: making bgworkers without shmem access actually not have shmem access
Re: making bgworkers without shmem access actually not have shmem access
List pgsql-hackers
I've complained about this problem a few times before: there's nothing
to prevent a background worker which doesn't request shared memory
access from calling InitProcess() and then accessing shared memory
anyway.  The attached patch is a first crack at fixing it.
Unfortunately, there's still a window between when we fork() and when
we detach shared memory, but that's also true for processes like
syslogger, whose death is nevertheless does not cause a
crash-and-restart.  Also unfortunately, in the EXEC_BACKEND case, we
actually have to attach shared memory first, to get our background
worker entry details. This is undesirable, but I'm not sure there's
any good way to fix it at all, and certainly not in time for 9.4.
Hopefully, the window when shared memory is attached with this patch
is short enough to make things relatively safe.

At a minimum, it's got to be better than the status quo, where shared
memory is accessible throughout the entire lifetime of
non-shmem-access background workers.

Attached is also a new background worker called say_hello which I used
for testing this patch.  That's obviously not for commit.

Comments?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment

pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Next
From: Andres Freund
Date:
Subject: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers