Re: file-locking and postmaster.pid

korry <korry(at)appx(dot)com> writes:
>> 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.

But then you've not accomplished anything. The complaints about the
pid-based mechanism are about false positives, not false negatives.
Adding an independent check won't eliminate the false positives.

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

We already have two platforms that don't use the SysV semaphore
interface, and even on ones that have it, I wouldn't want to assume they
all support SEM_UNDO.

But aside from any portability issues, ISTM this would have its own
failure modes. In particular you still have to rely on a pid-file
(only now it's holding a semaphore ID not a PID), and there's still
a bit of a leap of faith required to get from the observation that
somebody is holding a lock on semaphore X to the conclusion that that
somebody is a conflicting postmaster. It doesn't look to me like this
is any better than the PID solution, really, as far as false positives
go. As for false negatives: ipcrm.

regards, tom lane