Re: Weaker shmem interlock w/o postmaster.pid

On Wed, Sep 11, 2013 at 11:32:01AM -0400, Stephen Frost wrote:
> * Noah Misch (noah@leadboat.com) wrote:
> > The concrete situation in which I encountered this involved PostgreSQL 9.2 and
> > an immediate shutdown with a backend that had blocked SIGQUIT.  The backend
> > survived the immediate shutdown as one would expect.  
> 
> Well..  We expect this now because of the analysis you did in the
> adjacent thread showing how it can happen.

That was a surprising way for it to happen, but there have long been known
vectors like a SIGSTOP'd backend or a backend that has blocked SIGQUIT.

> > Concretely, that means
> > not removing postmaster.pid on immediate shutdown in 9.3 and earlier.  That's
> > consistent with the rough nature of an immediate shutdown, anyway.
> 
> I don't like leaving the postmaster.pid file around, even on an
> immediate shutdown.  I don't have any great suggestions regarding what
> to do, given what we try to do wrt 'immediate', so perhaps it's
> acceptable for future releases.

Fair enough.

> > 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.
> 
> The corruption risk, imv anyway, is sufficient to backpatch the change
> and overrides the concerns around very fast shutdown/restarts.

Making PGSharedMemoryCreate() pickier in all branches will greatly diminish
the marginal value of preserving postmaster.pid, so I'm fine with dropping the
postmaster.pid side of the proposal.

Thanks,
nm

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com