Building PG 8.2.3 for x86_64 on Mac OS X 10.4.9

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@speakeasy.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@speakeasy.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@genome.chop.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