469,106 Members | 2,262 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,106 developers. It's quick & easy.

Out of memory errors on OS X

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

Nov 23 '05 #1
7 1566
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

Nov 23 '05 #2
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

Nov 23 '05 #3
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)

Nov 23 '05 #4
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

Nov 23 '05 #5
> 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/
(303) 665-7007 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)

Nov 23 '05 #6
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

Nov 23 '05 #7
> 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/
(303) 665-7007 voice

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

Nov 23 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

31 posts views Thread by lawrence | last post: by
1 post views Thread by Murat Tasan | last post: by
1 post views Thread by Sean | last post: by
6 posts views Thread by Ganesan selvaraj | last post: by
18 posts views Thread by MajorSetback | last post: by
1 post views Thread by =?Utf-8?B?QU1lcmNlcg==?= | last post: by
27 posts views Thread by George2 | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by kglaser89 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.