Re: Weaker shmem interlock w/o postmaster.pid

On Wed, Sep 11, 2013 at 11:32:01AM -0400, Stephen Frost wrote:
> * Noah Misch (noah(at)leadboat(dot)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