Re: darwin pgsql patches - Mailing list pgsql-patches

From Tom Lane
Subject Re: darwin pgsql patches
Date
Msg-id 13702.975997886@sss.pgh.pa.us
Whole thread Raw
In response to Re: darwin pgsql patches  (Peter Bierman <bierman@apple.com>)
Responses Re: darwin pgsql patches
List 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 by date:

Previous
From: Peter Bierman
Date:
Subject: Re: darwin pgsql patches
Next
From: Peter Bierman
Date:
Subject: Re: darwin pgsql patches