Re: Weaker shmem interlock w/o postmaster.pid
От | Noah Misch |
---|---|
Тема | Re: Weaker shmem interlock w/o postmaster.pid |
Дата | |
Msg-id | 20140213140224.GC2709347@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: Weaker shmem interlock w/o postmaster.pid (Bruce Momjian <bruce@momjian.us>) |
Список | 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@leadboat.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
В списке pgsql-hackers по дате отправления: