Re: file-locking and postmaster.pid

<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 />