On Wed, Sep 11, 2013 at 11:32:01AM -0400, Stephen Frost wrote: > * Noah Misch (n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
