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