Building PG 8.2.3 for x86_64 on Mac OS X 10.4.9

Has anybody tried making a 64-bit PostgreSQL on an Apple XServe w/
Intel Woodcrest CPU's? My compile works, but the 'make check' fails
because of failure to allocate shared memory. There's plenty of SYSV
memory available.

I compiled using:

./configure --without-readline --prefix=/usr/local/pgsql-8.2.3
CFLAGS='-arch x86_64'

log/initdb.log contains:

creating template1 database in /usr/local/src/postgresql-8.2.3/src/
test/regress/./tmp_check/data/base/1 ... FATAL: \
could not create shared memory segment: Cannot allocate memory
DETAIL: Failed system call was shmget(key=1, size=1810432, 03600).
HINT: This error usually means that PostgreSQL's request for a
shared memory segment exceeded available memory or s\
wap space. To reduce the request size (currently 1810432 bytes),
reduce PostgreSQL's shared_buffers parameter (curre\
ntly 50) and/or its max_connections parameter (currently 10).

Output of: sudo ipcs -m -b:

Shared Memory:
T ID KEY MODE OWNER GROUP SEGSZ

(no shared memory segments in use)

/etc/sysctl.conf contains:

kern.sysv.shmmax=268435456
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=65536

I just started a 32-bit instance of PostgreSQL with no problems on
this box, and it showed:

sudo ipcs -m -b
Shared Memory:
T ID KEY MODE OWNER GROUP SEGSZ
m 131071 5432001 --rw------- postgres staff 126763008

Thanks,
Kevin Murphy

On Apr 19, 2007, at 3:21 PM, Kevin Murphy wrote:
> Has anybody tried making a 64-bit PostgreSQL on an Apple XServe w/
> Intel Woodcrest CPU's? My compile works, but the 'make check'
> fails because of failure to allocate shared memory. There's plenty
> of SYSV memory available.

The call to shmget() is failing with ENOMEM. A standalone SYSV
shared memory test program gives the same result when compiled with -
arch x86_64.

Harrumph.

-Kevin Murphy

Kevin Murphy wrote:
> On Apr 19, 2007, at 3:21 PM, Kevin Murphy wrote:
> >Has anybody tried making a 64-bit PostgreSQL on an Apple XServe w/
> >Intel Woodcrest CPU's? My compile works, but the 'make check'
> >fails because of failure to allocate shared memory. There's plenty
> >of SYSV memory available.
>
> The call to shmget() is failing with ENOMEM. A standalone SYSV
> shared memory test program gives the same result when compiled with -
> arch x86_64.

So this makes it a platform bug?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

A.M. wrote:
>> On Apr 19, 2007, at 3:21 PM, Kevin Murphy wrote:
>>> Has anybody tried making a 64-bit PostgreSQL on an Apple XServe w/
>>> Intel Woodcrest CPU's? My compile works, but the 'make check' fails
>>> because of failure to allocate shared memory. There's plenty of
>>> SYSV memory available.
>
> The configure script will likely still configure for the 32-bit
> headers (so size_t will be 32 bits incorrectly). It will take a little
> more autoconf hacking to get a 64-bit build.
sizeof(size_t) reports as 8.

-Kevin

Kevin Murphy <murphy2(at)speakeasy(dot)net> writes:
> Has anybody tried making a 64-bit PostgreSQL on an Apple XServe w/
> Intel Woodcrest CPU's? My compile works, but the 'make check' fails
> because of failure to allocate shared memory. There's plenty of SYSV
> memory available.

> creating template1 database in /usr/local/src/postgresql-8.2.3/src/
> test/regress/./tmp_check/data/base/1 ... FATAL: \
> could not create shared memory segment: Cannot allocate memory
> DETAIL: Failed system call was shmget(key=1, size=1810432, 03600).

Hmm ... not sure if this is related, but there's something mighty fishy
about that "key" parameter. I'd expect to see key=5432001, or something
close to that depending on what port number you're using.

regards, tom lane

Tom Lane wrote:
> Kevin Murphy <murphy2(at)speakeasy(dot)net> writes:
>
>> Has anybody tried making a 64-bit PostgreSQL on an Apple XServe w/
>> Intel Woodcrest CPU's?
>>
>> creating template1 database in /usr/local/src/postgresql-8.2.3/src/
>> test/regress/./tmp_check/data/base/1 ... FATAL: \
>> could not create shared memory segment: Cannot allocate memory
>> DETAIL: Failed system call was shmget(key=1, size=1810432, 03600).
>>
>
> Hmm ... not sure if this is related, but there's something mighty fishy
> about that "key" parameter. I'd expect to see key=5432001, or something
> close to that depending on what port number you're using.
>
But is this the case when doing 'make check'? I see this in postinit.c:

/*

* We're running a postgres bootstrap process or a
standalone backend.
* Create private "shmem" and
semaphores.

*/
CreateSharedMemoryAndSemaphores(true, 0);

where 0 is the port.

Since the ENOMEM problem occurs in a simple shared memory test program,
I'm inquiring on an Apple dev list.

-Kevin Murphy

Kevin Murphy <murphy(at)genome(dot)chop(dot)edu> writes:
> Tom Lane wrote:
>> Hmm ... not sure if this is related, but there's something mighty fishy
>> about that "key" parameter. I'd expect to see key=5432001, or something
>> close to that depending on what port number you're using.
>>
> But is this the case when doing 'make check'?

Oh, right, at that point it's a standalone backend not a postmaster,
so no port. Never Mind ...

> Since the ENOMEM problem occurs in a simple shared memory test program,
> I'm inquiring on an Apple dev list.

Sounds like a plan.

regards, tom lane

> On Apr 19, 2007, at 3:21 PM, Kevin Murphy wrote:
>> Has anybody tried making a 64-bit PostgreSQL on an Apple XServe w/
>> Intel Woodcrest CPU's? My compile works, but the 'make check'
>> fails because of failure to allocate shared memory. There's
>> plenty of SYSV memory available.
>
> The call to shmget() is failing with ENOMEM. A standalone SYSV
> shared memory test program gives the same result when compiled with
> -arch x86_64.
>

OK, I finally found someone (Terry Lambert at Apple) to answer my
question. Here's the thread:

http://lists.apple.com/archives/darwin-kernel/2007/Apr/msg00021.html

Excerpt: "It's trying to allocate the memory in the lower 4G of the
process virtual address space, and unless you turn off the 4G page 0
mapping (or munamp() it after you're running but before you attempt
to allocate shared memory), it's not going to see any free address
space available."

Regards,
Kevin Murphy