Re: file-locking and postmaster.pid
От | korry |
---|---|
Тема | Re: file-locking and postmaster.pid |
Дата | |
Msg-id | 1148509274.21335.90.camel@sakai.localdomain обсуждение исходный текст |
Ответ на | Re: file-locking and postmaster.pid (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: file-locking and postmaster.pid
|
Список | pgsql-hackers |
<blockquote type="CITE"><pre> <font color="#000000">> What we currently have in place is not bulletproof.</font> <font color="#000000">Well, it fails in the safe direction: the postmaster may occasionally</font> <font color="#000000">refuse to start when it should, but it won't ever start when it should</font> <font color="#000000">not. It appears to me that anything relying on file locking will tend</font> <font color="#000000">to fail in the other direction, and that's not acceptable IMHO.</font> </pre></blockquote><br /> I was suggesting that we keep the current check in place too - if the lock exists, another postmastermust be running, if the lock doesn't exist, check the pid.<br /><br /> However...<br /><br /> Thinking a littleharder about Andreas' original suggestion... what he's really suggesting is an exclusion mechanism that relies on thekernel to clean up after a shared process (with no danger of recycling, like a pid will do).<br /><br /> How about a semaphorewith a SEM_UNDO? That's guaranteed atomic (or it better be :-), the kernel automatically cleans up after a failure,if the mechanism fails, it fails in the safe direction (the kernel may not have cleaned up the semaphore before anew postmaster starts). And, I think it would be reasonably portable - I haven't carefully eyeballed the Win32 semaphorecode so I don't know if it supports SEM_UNDO.<br /><br /> (Sorry if this has been suggested before)<br /><br /> -- Korry<br /><br />
В списке pgsql-hackers по дате отправления: