Date: Mon, 4 Nov 2013 10:55:21 +0100
From: Andres Freund <andres@2ndquadrant.com>
To: Heikki Linnakangas <hlinnakangas@vmware.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
Message-ID: <20131104095521.GI3567@awork2.anarazel.de>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52775A83.7090206@vmware.com>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 2013-11-04 10:27:47 +0200, Heikki Linnakangas wrote:
> On 01.11.2013 18:22, Noah Misch wrote:
> >On Fri, Nov 01, 2013 at 12:27:31AM -0400, Robert Haas wrote:
> >>On Thu, Oct 31, 2013 at 7:48 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
> >>>On 31.10.2013 16:43, Robert Haas wrote:
> >>>>There should be no cases where the main shared memory
> >>>>segment gets cleaned up and the dynamic shared memory segments do not.
> >>>
> >>>1. initdb -D data1
> >>>2. initdb -D data2
> >>>3. postgres -D data1
> >>>4. killall -9 postgres
> >>>5. postgres -D data2
> >>>
> >>>The system V shmem segment orphaned at step 4 will be cleaned up at step 5.
> >>>The DSM segment will not.
> >
> >Note that dynamic_shared_memory_type='mmap' will give the desired behavior.

Well, with the significant price of causing file-io.

> 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.
Also, I don't think it's portable across platforms to access segments
that already have been unlinked.

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

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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