Re: Weaker shmem interlock w/o postmaster.pid
От | Noah Misch |
---|---|
Тема | Re: Weaker shmem interlock w/o postmaster.pid |
Дата | |
Msg-id | 20130912032520.GA261339@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: Weaker shmem interlock w/o postmaster.pid (David Johnston <polobo@yahoo.com>) |
Список | pgsql-hackers |
On Wed, Sep 11, 2013 at 07:57:22PM -0700, David Johnston wrote: > Noah Misch-2 wrote > > 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. > > Its probably still worth a fresh look at the immediate shutdown process to > see whether the current location where postmaster.pid is removed is > acceptable. It may not be necessary to leave it in place always but: > > 1) if there is a section of shared memory that can only be reached/found if > one knows the pid, and Similar: one needs a sysv shared memory key to find the segment, and postmaster.pid records that key. The chosen key is almost always the same from run to run, so a new postmaster typically does find the old segment even without postmaster.pid. > 2) postmaster.pid is removed before that area is "secured from future > clobbering" Clobbering shared memory is not the actual threat here. We use the shared memory segment as a witness to the fact that PostgreSQL processes are active in a data directory. If we let children of different postmasters operate in the same directory simultaneously, they can corrupt data. > then there may be a risk that can still be mitigated by moving its removal > without having to go to the extreme. -- Noah Misch EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: