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?

Reply via email to