Re: Weaker shmem interlock w/o postmaster.pid
От | Robert Haas |
---|---|
Тема | Re: Weaker shmem interlock w/o postmaster.pid |
Дата | |
Msg-id | CA+TgmoZJn7oF8uOQva4sBY=G04UHZ23+p=tjE9NueZsBvHMTFQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Weaker shmem interlock w/o postmaster.pid (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: Weaker shmem interlock w/o postmaster.pid
|
Список | pgsql-hackers |
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: