<blockquote type="CITE"><pre>
<font color="#000000">> You never need to reduce it to a shared lock. On postmaster startup,</font>
<font color="#000000">> try to lock the sentinel byte (one byte past the end-of-file). If you</font>
<font color="#000000">> can lock it, you know that no other postmaster has that byte locked. If</font>
<font color="#000000">> you can't lock it, another postmaster is running. It is an atomic</font>
<font color="#000000">> operation. </font>
<font color="#000000">This doesn't work if the postmaster dies but a backend continues to run,</font>
<font color="#000000">which is arguably the most important case we need to protect against.</font>
</pre></blockquote><br /> I may be confused here, but I don't see the problem - byte-range locks are not inherited
acrossa fork. A backend would never hold the lock, a backend would never even look for the lock.<br /><br /><br
/><blockquotetype="CITE"><pre>
<font color="#000000">> However, Tom may be correct about NFS locking, but I guess I'm surprised</font>
<font color="#000000">> that anyone would care :-)</font>
<font color="#000000">Quite a lot of people run NFS-mounted data directories ...</font>
</pre></blockquote><br /> I'm happy to take your word for that, and I agree that if NFS is important and locking is
brain-deadon NFS, then relying solely on a lock is unacceptable.<br /><br /><br /> -- Korry<br /><br />
