From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@2ndquadrant.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Something fishy happening on frogmouth
Date: Fri, 01 Nov 2013 01:48:58 +0200
Message-ID: <5272EC6A.2020004@vmware.com> (raw)
In-Reply-To: <CA+Tgmobk7nL8MAQdOVPTHzn2pA7aP-kfYvjHTqUsZnbu3FsOxQ@mail.gmail.com>
References: <6557.1383073940@sss.pgh.pa.us>
<CA+Tgmob859sdnDuHAF31BE55qEoREnCzzWeqDbgkNB0d_F+zmA@mail.gmail.com>
<27889.1383139602@sss.pgh.pa.us>
<20131030133718.GB11429@awork2.anarazel.de>
<28492.1383140966@sss.pgh.pa.us>
<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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: hlinnakangas@vmware.com, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, andres@2ndquadrant.com, andrew@dunslane.net
Subject: Re: Something fishy happening on frogmouth
In-Reply-To: <5272EC6A.2020004@vmware.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox