From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Dynamic Shared Memory stuff |
Date: | 2013-12-06 16:39:23 |
Message-ID: | CA+TgmoakLk2v71S-mftk-dRjHtrxqMCy0vFk4HCm5xszsks7hQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 5, 2013 at 4:06 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
>> 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.
OK, let me work on that once this CommitFest is done.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Álvaro Hernández Tortosa | 2013-12-06 17:29:28 | Re: RFC: programmable file format for postgresql.conf |
Previous Message | Tom Lane | 2013-12-06 16:27:17 | Re: Proof of concept: standalone backend with full FE/BE protocol |