Re: file-locking and postmaster.pid

> What we currently have in place is not bulletproof.

Well, it fails in the safe direction: the postmaster may occasionally
refuse to start when it should, but it won't ever start when it should
not.  It appears to me that anything relying on file locking will tend
to fail in the other direction, and that's not acceptable IMHO.

 I was suggesting that we keep the current check in place too - if the lock exists, another postmaster must be running, if the lock doesn't exist, check the pid.

 However...

 Thinking a little harder about Andreas' original suggestion... what he's really suggesting is an exclusion mechanism that relies on the kernel to clean up after a shared process (with no danger of recycling, like a pid will do).

 How about a semaphore with 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 a new postmaster starts).  And, I think it would be reasonably portable - I haven't carefully eyeballed the Win32 semaphore code so I don't know if it supports SEM_UNDO.

 (Sorry if this has been suggested before)

             -- Korry