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