From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Dynamic Shared Memory stuff |
Date: | 2013-12-05 21:06:33 |
Message-ID: | 52A0EAD9.8030703@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/05/2013 09:34 PM, Robert Haas wrote:
> On Thu, Dec 5, 2013 at 11:12 AM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Omar Kilani | 2013-12-05 21:14:09 | How to detect invisible rows caused by the relfrozenxid bug? |
Previous Message | Heikki Linnakangas | 2013-12-05 21:01:28 | Re: Proof of concept: standalone backend with full FE/BE protocol |