Which platforms, just out of curiousity? I assume that Win32 is one of them.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.
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.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)
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.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 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.
Yes, that's a problem, but I think it's the same as "rm postmaster.pid", isn't it?As for false negatives: ipcrm.