Re: file-locking and postmaster.pid

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

Which platforms, just out of curiousity? I assume that Win32 is one of
them.

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

You've lost me... why would you store the semid and not the pid? I was
thinking that the semid might be a postgresql.conf thingie.

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

Isn't that sort of like saying that if a postmaster.pid file exists, it
must have been written by a postmaster? Pick a semaphore id and
dedicate it to postmaster exclusion.

> It doesn't look to me like this
> is any better than the PID solution, really, as far as false positives
> go.

As long as the kernel cleans up SEM_UNDO semaphores, I guess I don't see
have you would have a false positive. Oh, I guess I should say that is
you use a SEM_UNDO semaphore, you don't need the pid check anymore.
And, no worry about NFS.

> As for false negatives: ipcrm.

Yes, that's a problem, but I think it's the same as "rm postmaster.pid",
isn't it?