Re: HEADS UP: Win32/OS2/BeOS native ports - Mailing list pgsql-hackers

From Joel Burton
Subject Re: HEADS UP: Win32/OS2/BeOS native ports
Date
Msg-id JGEPJNMCKODMDHGOBKDNIENJCMAA.joel@joelburton.com
Whole thread Raw
In response to Re: HEADS UP: Win32/OS2/BeOS native ports  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: HEADS UP: Win32/OS2/BeOS native ports  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: HEADS UP: Win32/OS2/BeOS native ports  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
Re: HEADS UP: Win32/OS2/BeOS native ports  ("Marc G. Fournier" <scrappy@hub.org>)
List pgsql-hackers
> "Joel Burton" <joel@joelburton.com> writes:
> >> Rather than propagating the SysV semaphore API still further, why don't
> >> we kill it now?  (I'm willing to keep the shmem API, however.)
>
> > Would this have the benefit of allow PostgreSQL to work properly in BSD
> > jails, since lack of really working SysV IPC was the problem there?
>
> Was the problem just with semas, or was shmem an issue too?

Not sure -- doesn't get far enough for me to tell. initdb dies with:

creating template1 database in /usr/local/pgsql/data/base/1...
IpcSemaphoreCreate: semget(key=1, num=17, 03600) failed:
Function not implemented

> In any case, unless someone actually writes an alternative sema
> implementation that will work on BSD, nothing will happen...

Was hoping that the discussions about the APR might let this work under BSD
jails, assuming I can get the APR to compile.

(For others: apparently PG will work under BSD jails if you recompile the
BSD kernel w/some new settings, but my ISP for this project was unwilling to
do that. Search the mailing list for messages on how to do this.)

J.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: HEADS UP: Win32/OS2/BeOS native ports
Next
From: "Dann Corbit"
Date:
Subject: Re: HEADS UP: Win32/OS2/BeOS native ports