Peter Bierman <bierman@apple.com> writes:
> Q2) As I'm 95% done making it work as a shim, I notice that the Sem
> stuff is shimmed in Postgres also, and I wonder if there'd be
> objections to me conditionalizing it there. It would be a LOT easier
> to change the InternalIpc...() to use POSIX named semaphores vs my
> current route of implementing SysV semaphores as a shim on top of
> POSIX ones.
POSIX IPC isn't compatible with SysV IPC? News to me. Chapter and
verse, please?
> Also, one of the things that got me into a mess is that the postmaster
> allocates some sem arrays via semget(), and then lets its children use
> the semids that were returned in the parent process. I can't find any
> docs that say this is legal, though obviously it must work. The
> Vahalia book on Unix Internals describes implementation that explains
> *why* it works, but sort off alludes that it shouldn't.
Nonsense. HPUX's semget() man page says:
... This call creates a new identifier,
subject to available resources. The identifier is never returned
by another call to semget() until it has been released by a call
to semctl(). The identifier should be used among the calling
process and its descendents; however, it is not a requirement.
The resource can be accessed by any process having the proper
permissions.
I'd say that makes it perfectly clear that semaphore identifiers are
system-wide, and *certainly* makes it clear that a semid may be passed
down to child processes.
> Also, should I be asking these questions on pg-hackers instead of here?
Probably. I don't think pgpatches is very widely read.
regards, tom lane
