Re: semaphore usage "port based"? - Mailing list pgsql-hackers

Robert Watson <rwatson@FreeBSD.org> writes:
> However, pid's in general uniquely identify a process only at the time they 
> are recorded.  So any pid returned here is necessarily stale -- even if there
> is another process with the pid returned by GETPID, it may actually be a 
> different process that has ended up with the same pid.  The longer the gap 
> since the last semaphore operation, the more likely (presumably) it is that 
> the pid has been recycled.  And on modern systems with thousands of processes
> and high process turn-over (i.e., systems with CGI and other sorts of 
> scripting),pid reuse can happen quickly.  Is your use of the pid here 
> consistent with fact that pid's are reused quickly after process exit?

That's a fair question, but in the context of the code I believe we are
behaving reasonably.  The reason this code exists is to provide some
insurance against leaking semaphores when a postmaster process is
terminated unexpectedly (ye olde often-recommended-against "kill -9
postmaster", for instance).  If the PID returned by GETPID is
nonexistent or belongs to a process not owned by the postgres userid
then we assume that the semaphore set can be recycled.  We could get
fooled by PID recycling if the PID returned by GETPID belongs to a
postgres-owned process that isn't actually the original owner, but
the penalty is just that we'll fail to recycle semaphores that could
be released.  Not very harmful, and not very probable either, unless
you're running postgres under a userid that's used for a lot of other
stuff too.  There is not much risk of long-term leakage of many
semaphore sets, even if you've got lots of postmaster crashes going on
(which I sure hope you don't).  The code is designed to retry the same
semaphore keys on each cycle of life, so you'd have to get fooled by
chance coincidence of existing PIDs every time over many cycles to
have a severe resource-leakage problem.  (BTW, Marc, that's the reason
for *not* randomizing the key selection as you suggested.)

So I think the code is pretty bulletproof as long as it's in a system
that is behaving per SysV spec.  The problem in the current FBSD
situation is that the jail mechanism is exposing semaphore sets across
jails, but not exposing the existence of the owning processes.  That
behavior is inconsistent: if process A can affect the state of a sema
set that process B can see, it's surely unreasonable to pretend that A
doesn't exist.
        regards, tom lane