Out of memory errors on OS X

[Jeffrey Melloy]

I have a couple users trying to install Postgres on OS X. To the best
of my knowledge, both of them are using 7.4.5/10.3.5, and got identical
errors while trying to init the database:

Reducing the shared buffers didn't help.

Any thoughts would be appreciated.

Jeffrey Melloy
jm*****@visualdistortion.org

William-Rowcliffes-Computer:/Users/wmrowcliffe postgres$
/usr/local/bin/initdb -D /usr/local/pgsql/data
The files belonging to this database system will be owned by user
"postgres".
This user must also own the server process.

The database cluster will be initialized with locale C.

fixing permissions on existing directory /usr/local/pgsql/data... ok
creating directory /usr/local/pgsql/data/base... ok
creating directory /usr/local/pgsql/data/global... ok
creating directory /usr/local/pgsql/data/pg_xlog... ok
creating directory /usr/local/pgsql/data/pg_clog... ok
selecting default max_connections... 10
selecting default shared_buffers... 50
creating configuration files... ok
creating template1 database in /usr/local/pgsql/data/base/1... FATAL:
could not create shared memory segment: Cannot allocate memory
DETAIL: Failed system call was shmget(key=1, size=1081344, 03600).
HINT: This error usually means that PostgreSQL's request for a shared
memory segment exceeded available memory or swap space. To reduce the
request size (currently 1081344 bytes), reduce PostgreSQL's
shared_buffers parameter (currently 50) and/or its max_connections
parameter (currently 10).
The PostgreSQL documentation contains more information about
shared memory configuration.

initdb: failed

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Neil Conway]

On Thu, 2004-09-30 at 13:49, Jeffrey Melloy wrote:

I have a couple users trying to install Postgres on OS X. To the best
of my knowledge, both of them are using 7.4.5/10.3.5, and got identical
errors while trying to init the database:

Have you tried the suggestions in the documentation?

http://www.postgresql.org/docs/7.4/s...s.html#SYSVIPC

-Neil

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Tom Lane]

Jeffrey Melloy <jm*****@visualdistortion.org> writes:

I have a couple users trying to install Postgres on OS X. To the best
of my knowledge, both of them are using 7.4.5/10.3.5, and got identical
errors while trying to init the database:

They need to increase the system's shmmax limit (sysctl kern.sysv.shmmax,
which is only 4MB by default). You can run one postmaster that way ...
not very well, but it will run ... but you definitely can't start two.
I surmise that they already had one postmaster running?

In OSX 10.3 I believe that the recommended way to fix this is to edit
/etc/rc's setting, and then reboot. AFAICS there is no reason not to
raise shmmax to 50% or so of physical RAM.

I have asked Apple about using a saner default for shmmax, but a few
more complaints in their bug system wouldn't hurt.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Jeffrey Melloy]

Tom Lane wrote:

Jeffrey Melloy <jm*****@visualdistortion.org> writes:

I have a couple users trying to install Postgres on OS X. To the best
of my knowledge, both of them are using 7.4.5/10.3.5, and got identical
errors while trying to init the database:

They need to increase the system's shmmax limit (sysctl kern.sysv.shmmax,
which is only 4MB by default). You can run one postmaster that way ...
not very well, but it will run ... but you definitely can't start two.
I surmise that they already had one postmaster running?

In OSX 10.3 I believe that the recommended way to fix this is to edit
/etc/rc's setting, and then reboot. AFAICS there is no reason not to
raise shmmax to 50% or so of physical RAM.

I have asked Apple about using a saner default for shmmax, but a few
more complaints in their bug system wouldn't hurt.

regards, tom lane

I'll pass it on, though I'm wondering why they would have that problem
and others (myself included) don't.

Jeff

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

[Kevin Barnard]

Maybe this is a server vs normal OS X issue. I am postgres on a
normal iMac 10.3.5 with no problems, but this is just a developent box
so I don't need the server version. All of the servers that I run are
Linux/FreeBSD. I don't have access to a Mac server, if I did I would
test this myself.
On Wed, 29 Sep 2004 23:24:38 -0500, Jeffrey Melloy
<jm*****@visualdistortion.org> wrote:

I'll pass it on, though I'm wondering why they would have that problem
and others (myself included) don't.

Jeff

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Scott Ribe]

> I have asked Apple about using a saner default for shmmax, but a few

more complaints in their bug system wouldn't hurt.

I suspect it won't help, since their official position is already "don't use
shmget, use mmap instead"...
--
Scott Ribe
sc********@killerbytes.com
http://www.killerbytes.com/
[phone] voice

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

[Tom Lane]

Scott Ribe <sc********@killerbytes.com> writes:

I have asked Apple about using a saner default for shmmax, but a few
more complaints in their bug system wouldn't hurt.

I suspect it won't help, since their official position is already "don't use
shmget, use mmap instead"...

Given that they have improved their SysV IPC support steadily over the
past few Darwin releases, I don't see why you'd expect them to not be
willing to do this. Having a larger default limit costs them *zero* if
the feature is not used, so what's the objection?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Scott Ribe]

> Given that they have improved their SysV IPC support steadily over the

past few Darwin releases, I don't see why you'd expect them to not be
willing to do this. Having a larger default limit costs them *zero* if
the feature is not used, so what's the objection?

The objection would be attitudinal. I detect a whiff of "that's sooo
obsolete, you should get with the program and do it our way instead" in
their docs...
--
Scott Ribe
sc********@killerbytes.com
http://www.killerbytes.com/
[phone] voice

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org