Re: Weaker shmem interlock w/o postmaster.pid - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Weaker shmem interlock w/o postmaster.pid
Date
Msg-id 20140212230640.GB4831@momjian.us
Whole thread Raw
In response to Re: Weaker shmem interlock w/o postmaster.pid  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Weaker shmem interlock w/o postmaster.pid  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Wed, Sep 11, 2013 at 02:10:45PM -0400, Robert Haas wrote:
> On Tue, Sep 10, 2013 at 11:33 PM, Noah Misch <noah@leadboat.com> wrote:
> > I'm thinking to preserve postmaster.pid at immediate shutdown in all released
> > versions, but I'm less sure about back-patching a change to make
> > PGSharedMemoryCreate() pickier.  On the one hand, allowing startup to proceed
> > with backends still active in the same data directory is a corruption hazard.
> > On the other hand, it could break weird shutdown/restart patterns that permit
> > trivial lifespan overlap between backends of different postmasters.  Opinions?
> 
> I'm more sanguine about the second change than the first.  Leaving
> postmaster.pid around seems like a clear user-visible behavior change
> that could break user scripts or have other consequences that we don't
> foresee; thus, I would vote against back-patching it.  Indeed, I'm not
> sure it's a good idea to do that even in master.  On the other hand,
> tightening the checks in PGSharedMemoryCreate() seems very much worth
> doing, and I think it might also be safe enough to back-patch.

Were these changes every applied?  I don't see them.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Marti Raudsepp
Date:
Subject: Re: PoC: Partial sort
Next
From: Craig Ringer
Date:
Subject: Re: narwhal and PGDLLIMPORT