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