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

Re: darwin pgsql patches

From: Peter Bierman <bierman(at)apple(dot)com>
To: pgsql-patches(at)postgresql(dot)org
Subject: Re: darwin pgsql patches
Date: 2000-12-05 06:02:55
Message-ID: v03130310b652309ce853@[] (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
At 12:30 PM -0500 12/2/00, Tom Lane wrote:

>You might want to think about having the template/darwin file add
>-D__darwin__ to CPPFLAGS, instead of putting a #define in port/darwin.h.

This is what I ended up with.

My plans for the #include "../backend/port/darwin/sem.h" are to change the in the directories that have source that needs to #include my "sem.h" to add a -I../backend/port/darwin/  That way the change happens from inside the source tree, no worries about the header search tree moving. Any objections?

Finally, after one of our kernel engineers gave me the skinny on semaphore support, I almost have it working correctly. I've made a LOT of changes to the qnx shim to use named POSIX semaphores. The general method sort of the same, and I've also added a ton of conditional debugging output.

Two questions:

Q1) should I submit with the debugging stuff in the code (conditionalized off of course). It's useful if someone wants to see how it works, but it makes the code a bit harder to read.

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.

I could conditionalize the code on HAS_POSIX_SEMAPHORES or DARWIN_HAS_POSIX_SEMAPHORES, and only set it on darwin for now. Other platforms could try it and migrate over if it works. Part of me thinks this would be better for PG as a whole, moving towards POSIX and all that...


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.

Also, should I be asking these questions on pg-hackers instead of here?


"Every time you provide an option, you're asking the user to make a decision.
 That means they will have to think about something and decide about it.
 It's not necessarily a bad thing, but, in general, you should always try to
 minimize the number of decisions that people have to make."$51

In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2000-12-05 06:31:26
Subject: Re: darwin pgsql patches
Previous:From: Tom LaneDate: 2000-12-02 17:30:54
Subject: Re: darwin pgsql patches

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