From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Weaker shmem interlock w/o postmaster.pid |
Date: | 2014-02-13 14:02:24 |
Message-ID: | 20140213140224.GC2709347@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 12, 2014 at 06:06:40PM -0500, Bruce Momjian wrote:
> 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(at)leadboat(dot)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.
No, I haven't gotten around to writing them.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2014-02-13 14:07:01 | Re: [BUG] Archive recovery failure on 9.3+. |
Previous Message | Heikki Linnakangas | 2014-02-13 14:01:16 | Re: [BUG] Archive recovery failure on 9.3+. |