Skip site navigation (1) Skip section navigation (2)

Re: darwin pgsql patches

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Bierman <bierman(at)apple(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: darwin pgsql patches
Date: 2000-12-05 06:31:26
Message-ID: 13702.975997886@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Peter Bierman <bierman(at)apple(dot)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

In response to

Responses

pgsql-patches by date

Next:From: Peter BiermanDate: 2000-12-05 06:44:58
Subject: Re: darwin pgsql patches
Previous:From: Peter BiermanDate: 2000-12-05 06:02:55
Subject: Re: darwin pgsql patches

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group