Re: darwin pgsql patches - Mailing list pgsql-patches

From Tom Lane
Subject Re: darwin pgsql patches
Date
Msg-id 21508.976045580@sss.pgh.pa.us
Whole thread Raw
In response to Re: darwin pgsql patches  (Ian Lance Taylor <ian@airs.com>)
Responses Re: darwin pgsql patches
Re: darwin pgsql patches
List pgsql-patches
Ian Lance Taylor <ian@airs.com> writes:
>    Where can I find
>    a description of the POSIX version of semaphores?

> POSIX semaphores can in principle live in either user space or kernel
> space.  They are mainly designed for user space, though.

> If you have access to a GNU/Linux system, you can do `man sem_init'.
> Or, I just did a quick web search, and found this:
>     http://helix.nih.gov/cgi-bin/man.cgi?section=3&topic=sem_init

Hm.  It's clearly possible to base Postgres's semaphore stuff on unnamed
Posix semaphores living in the shared memory area (which eliminates the
issue of inheritance by child processes).  You'd need to revise the API
presented by ipc.c so that it doesn't depend on semaphore IDs and keys.
I'm inclined to envision a type "pg_semaphore" that's either "sem_t" in
the POSIX case or
    struct { int sem_id, sem_num; }
in the SysV case, and then all the ipc.c routines take a pg_semaphore *.
There's some code to allocate semaphores to backends in proc.c that
would need to be rewritten, but the impact ought to be pretty localized.

How efficient are POSIX semaphores, anyway?  I wonder if we couldn't
also replace spinlocks with them...

>    BTW, should I expect that POSIX also ignored the SysV IPC spec for
>    shared memory?

> Yes.  POSIX.1 standardizes mmap instead.

Another TODO item I suppose :-(

            regards, tom lane

pgsql-patches by date:

Previous
From: Ian Lance Taylor
Date:
Subject: Re: darwin pgsql patches
Next
From: Tom Lane
Date:
Subject: Re: Fixes for checking unique constraints on RI creation