Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VdFW4-0002n6-94 for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Nov 2013 08:28:08 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VdFW3-0004Hp-4X for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Nov 2013 08:28:07 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VdFW1-0004Hg-UB for pgsql-hackers@postgresql.org; Mon, 04 Nov 2013 08:28:06 +0000 Received: from smtp-outbound-2.vmware.com ([208.91.2.13]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VdFVy-0006E6-AE for pgsql-hackers@postgresql.org; Mon, 04 Nov 2013 08:28:04 +0000 Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 0C16829448; Mon, 4 Nov 2013 00:28:01 -0800 (PST) Received: from zcs-prod-ext-mta-2.vmware.com (zcs-prod-ext-mta-2.vmware.com [10.113.62.224]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 06F10B059B; Mon, 4 Nov 2013 00:28:01 -0800 (PST) Received: from zcs-prod-ext-mta-2.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-ext-mta-2.vmware.com (Postfix) with ESMTP id 609ECC005A; Mon, 4 Nov 2013 00:28:17 -0800 (PST) Received: from [192.168.1.90] (zimbra-prod-ext-proxy-vip.vmware.com [10.113.63.87]) by zcs-prod-ext-mta-2.vmware.com (Postfix) with ESMTPSA; Mon, 4 Nov 2013 00:28:14 -0800 (PST) Message-ID: <52775A83.7090206@vmware.com> Date: Mon, 04 Nov 2013 10:27:47 +0200 From: Heikki Linnakangas 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: Noah Misch CC: Robert Haas , Tom Lane , Andres Freund , Andrew Dunstan , "pgsql-hackers@postgresql.org" Subject: Re: Something fishy happening on frogmouth References: <20131030133718.GB11429@awork2.anarazel.de> <28492.1383140966@sss.pgh.pa.us> <527223E8.2020207@vmware.com> <20131031095021.GA31628@alap2.anarazel.de> <22875.1383229757@sss.pgh.pa.us> <5272EC6A.2020004@vmware.com> <20131101162230.GA649568@tornado.leadboat.com> In-Reply-To: <20131101162230.GA649568@tornado.leadboat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -6.9 (------) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org 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 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. 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(). I'm not sure how dynamic these segments need to be, but if 1-2 such file descriptors is not enough, you could mmap() different offsets from the same shmem object for different segments. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers