From: Noah Misch <noah@leadboat.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Heikki Linnakangas <hlinnakangas@vmware.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, 1 Nov 2013 12:22:30 -0400
Message-ID: <20131101162230.GA649568@tornado.leadboat.com> (raw)
In-Reply-To: <CA+TgmoZhFZkdywhCwu-kB9CdrPz_gZ6scSjSjBpjE3W4FPAu=g@mail.gmail.com>
References: <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>
<5272EC6A.2020004@vmware.com>
<CA+TgmoZhFZkdywhCwu-kB9CdrPz_gZ6scSjSjBpjE3W4FPAu=g@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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.
> If we want the behavior, we could mimic what the main shared memory
> code does here: instead of choosing a random value for the control
> segment identifier and saving it in a state file, start with something
> like port * 100 + 1000000 (the main shared memory segment uses port *
> 100, so we'd want something at least slightly different) and search
> forward one value at a time from there until we find an unused ID.
This approach used for the main sysv segment has its own problems. If the
first postmaster had to search forward but the second postmaster does not, the
second postmaster will not reach the old segment to clean it up.
It might be suitably-cheap insurance to store the DSM control segment handle
in PGShmemHeader. Then if, by whatever means good or bad, we find a main sysv
segment to clean up, we can always clean up the associated DSM segment(s).
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
--
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: noah@leadboat.com, robertmhaas@gmail.com, hlinnakangas@vmware.com, tgl@sss.pgh.pa.us, andres@2ndquadrant.com, andrew@dunslane.net
Subject: Re: Something fishy happening on frogmouth
In-Reply-To: <20131101162230.GA649568@tornado.leadboat.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