Re: darwin pgsql patches
От | Tom Lane |
---|---|
Тема | Re: darwin pgsql patches |
Дата | |
Msg-id | 13702.975997886@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: darwin pgsql patches (Peter Bierman <bierman@apple.com>) |
Ответы |
Re: darwin pgsql patches
|
Список | pgsql-patches |
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
В списке pgsql-patches по дате отправления: