Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vc201-0004m4-QN for pgsql-hackers@arkaria.postgresql.org; Thu, 31 Oct 2013 23:50:02 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Vc201-0004T8-07 for pgsql-hackers@arkaria.postgresql.org; Thu, 31 Oct 2013 23:50:01 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vc1zz-0004Sv-78 for pgsql-hackers@postgresql.org; Thu, 31 Oct 2013 23:49:59 +0000 Received: from smtp-outbound-2.vmware.com ([208.91.2.13]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vc1zv-00057E-Cu for pgsql-hackers@postgresql.org; Thu, 31 Oct 2013 23:49:57 +0000 Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 661C0297B9; Thu, 31 Oct 2013 16:49:43 -0700 (PDT) Received: from zcs-prod-ext-mta-1.vmware.com (zcs-prod-ext-mta-1.vmware.com [10.113.62.223]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 5F60D4037F; Thu, 31 Oct 2013 16:49:43 -0700 (PDT) Received: from zcs-prod-ext-mta-1.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-ext-mta-1.vmware.com (Postfix) with ESMTP id 91D2912000B; Thu, 31 Oct 2013 16:56:48 -0700 (PDT) Received: from [10.7.10.144] (zimbra-prod-ext-proxy-vip.vmware.com [10.113.63.87]) by zcs-prod-ext-mta-1.vmware.com (Postfix) with ESMTPSA; Thu, 31 Oct 2013 16:56:43 -0700 (PDT) Message-ID: <5272EC6A.2020004@vmware.com> Date: Fri, 01 Nov 2013 01:48:58 +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: Robert Haas CC: Tom Lane , Andres Freund , Andrew Dunstan , "pgsql-hackers@postgresql.org" Subject: Re: Something fishy happening on frogmouth References: <6557.1383073940@sss.pgh.pa.us> <27889.1383139602@sss.pgh.pa.us> <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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -7.4 (-------) 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 31.10.2013 16:43, Robert Haas wrote: > Let me say this again: the dynamic shared memory code *does* clean up > after itself. If you kill -9 the postmaster and all of its children, > you'll orphan the main shared memory segment and any dynamic shared > memory segments that exist. There is nothing we can do about that. > When you restart the postmaster, both the main shared memory segment > and any dynamic shared memory segments orphaned by the previous kill > will be cleaned up. I spent a lot of time trying to make sure that > the handling of dynamic shared memory segments is, in all cases, as > parallel to the handling of the main shared memory segment as > possible. 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. BTW, 9.3 actually made the situation a lot better for the main memory segment. You only leak the small interlock shmem segment, the large mmap'd block does get automatically free'd when the last process using it exits. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers