Message-ID: <52778157.9050907@vmware.com>
Date: Mon, 04 Nov 2013 13:13:27 +0200
From: Heikki Linnakangas <hlinnakangas@vmware.com>
Organization: VMware
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20131005 Icedove/17.0.9
MIME-Version: 1.0
To: Andres Freund <andres@2ndquadrant.com>
CC: Noah Misch <noah@leadboat.com>, Robert Haas <robertmhaas@gmail.com>,
 Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Something fishy happening on frogmouth
References: 
 <CA+TgmobOqYVBD=xdWHF12R4+dxeBDS3ruxware7ZWtD5mfSO5Q@mail.gmail.com>
 <527223E8.2020207@vmware.com> <20131031095021.GA31628@alap2.anarazel.de>
 <CA+Tgmoa6gJAPeMKCK77xzUbhqriO0C+24Ow7ezz4GP8wHCF-EA@mail.gmail.com>
 <22875.1383229757@sss.pgh.pa.us>
 <CA+Tgmobk7nL8MAQdOVPTHzn2pA7aP-kfYvjHTqUsZnbu3FsOxQ@mail.gmail.com>
 <5272EC6A.2020004@vmware.com>
 <CA+TgmoZhFZkdywhCwu-kB9CdrPz_gZ6scSjSjBpjE3W4FPAu=g@mail.gmail.com>
 <20131101162230.GA649568@tornado.leadboat.com> <52775A83.7090206@vmware.com>
 <20131104095521.GI3567@awork2.anarazel.de>
In-Reply-To: <20131104095521.GI3567@awork2.anarazel.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 04.11.2013 11:55, Andres Freund wrote:
> On 2013-11-04 10:27:47 +0200, Heikki Linnakangas wrote:
>> Hmm, here's another idea:
>>
>> Postmaster creates the POSIX shared memory object at startup, by calling
>> shm_open(), and immediately calls shm_unlink on it. That way, once all the
>> processes have exited, the object will be removed automatically. Child
>> processes inherit the file descriptor at fork(), and don't need to call
>> shm_open, just mmap().
>
> Uh. Won't that completely and utterly remove the point of dsm which is
> that you can create segments *after* startup? We surely don't want to
> start overallocating enough shmem so we don't ever dynamically need to
> allocate segments.

You don't need to allocate the shared memory beforehand, only create the 
file descriptor. Note that the size of the segment is specified in the 
shm_open() call, but the mmap() that comes later.

If we need a large amount of small segments, so that it's not feasible 
to shm_open() them all at postmaster startup, you could shm_open() just 
one segment, and carve out smaller segments from it by mmap()ing at 
different offsets.

> Also, I don't think it's portable across platforms to access segments
> that already have been unlinked.

See 
http://pubs.opengroup.org/onlinepubs/009695299/functions/shm_unlink.html: "If 
one or more references to the shared memory object exist when the object 
is unlinked, the name shall be removed before shm_unlink() returns, but 
the removal of the memory object contents shall be postponed until all 
open and map references to the shared memory object have been removed."

That doesn't explicitly say that a new shm_open() on the file descriptor 
must still work after shm_unlink, but I would be surprised if there is a 
platform where it doesn't.

> I think this is looking for a solution without an actually relevant
> problem disregarding the actual problem space.

I agree. What are these dynamic shared memory segments supposed to be 
used for?

- Heikki


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers