On 12/05/2013 09:34 PM, Robert Haas wrote:
On Thu, Dec 5, 2013 at 11:12 AM, Heikki Linnakangas
<hlinnakan...@vmware.com> wrote:
One idea is to create the shared memory object with shm_open, and wait until
all the worker processes that need it have attached to it. Then,
shm_unlink() it, before using it for anything. That way the segment will be
automatically released once all the processes close() it, or die. In
particular, kill -9 will release it. (This is a variant of my earlier idea
to create a small number of anonymous shared memory file descriptors in
postmaster startup with shm_open(), and pass them down to child processes
with fork()). I think you could use that approach with SysV shared memory as
well, by destroying the segment with sgmget(IPC_RMID) immediately after all
processes have attached to it.
That's a very interesting idea. I've been thinking that we needed to
preserve the property that new workers could attach to the shared
memory segment at any time, but that might not be necessary in all
case. We could introduce a new dsm operation that means "i promise no
one else needs to attach to this segment". Further attachments would
be disallowed by dsm.c regardless of the implementation in use, and
dsm_impl.c would also be given a chance to perform
implementation-specific operations, like shm_unlink and
shmctl(IPC_RMID). This new operation, when used, would help to reduce
the chance of leaks and perhaps catch other programming errors as
well.
What should we call it? dsm_finalize() is the first thing that comes
to mind, but I'm not sure I like that.
dsm_unlink() would mirror the underlying POSIX shm_unlink() call, and
would be familiar to anyone who understands how unlink() on a file works
on Unix.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
