Thread: OS X Tiger, and PostgreSQL 8.2 don't mix?
I have OS X tiger with all the updates:
uname -r
8.8.0
Here is what I get when I try to initdb on a freshly compiled 8.2:
selecting default max_connections ... 10
selecting default shared_buffers/max_fsm_pages ... 400kB/20000
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=2, size=1646592, 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 1646592 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.
child process exited with exit code 1
I read the documentation
(http://www.postgresql.org/docs/8.2/static/kernel-resources.html) and
added the appropriate items to /etc/sysctl.conf, and I rebooted for it
to take effect.
cat /etc/sysctl.conf
kern.sysv.shmmax=4194304
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024
I still get the error when I initdb. OS X and PostgreSQL has worked
before for me, compiled from the source.
regards,
karen
> I have OS X tiger with all the updates: > > uname -r > 8.8.0 > > Here is what I get when I try to initdb on a freshly compiled 8.2: > > selecting default max_connections ... 10 > selecting default shared_buffers/max_fsm_pages ... 400kB/20000 > 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=2, size=1646592, 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 1646592 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. > child process exited with exit code 1 > Works for me :| (see initdb output below)... > > I read the documentation > (http://www.postgresql.org/docs/8.2/static/kernel-resources.html) and > added the appropriate items to /etc/sysctl.conf, and I rebooted for it > to take effect. > > cat /etc/sysctl.conf > kern.sysv.shmmax=4194304 > kern.sysv.shmmin=1 > kern.sysv.shmmni=32 > kern.sysv.shmseg=8 > kern.sysv.shmall=1024 Can you check whether the settings worked? Do: ibook:~ chris$ sysctl -a | grep shm kern.sysv.shmmax: 4194304 kern.sysv.shmmin: 1 kern.sysv.shmmni: 32 kern.sysv.shmseg: 8 kern.sysv.shmall: 1024 Bye, Chris. --------------------------------------------------------------------- ibook:/opt/pg chris$ initdb The files belonging to this database system will be owned by user "chris". This user must also own the server process. The database cluster will be initialized with locale C. creating directory /opt/pg/data ... ok creating subdirectories ... ok selecting default max_connections ... 30 selecting default shared_buffers/max_fsm_pages ... 2400kB/20000 creating configuration files ... ok creating template1 database in /opt/pg/data/base/1 ... ok initializing pg_authid ... ok initializing dependencies ... ok creating system views ... ok loading system objects' descriptions ... ok creating conversions ... ok setting privileges on built-in objects ... ok creating information schema ... ok vacuuming database template1 ... ok copying template1 to template0 ... ok copying template1 to postgres ... ok WARNING: enabling "trust" authentication for local connections You can change this by editing pg_hba.conf or using the -A option the next time you run initdb. Success. You can now start the database server using: postgres -D /opt/pg/data or pg_ctl -D /opt/pg/data -l logfile start ibook:/opt/pg chris$ uname -r 8.8.0 ---------------------------------------------------------------------
"Karen Hill" <karen_hill22@yahoo.com> writes:
> I still get the error when I initdb. OS X and PostgreSQL has worked
> before for me, compiled from the source.
Works for me. What do you get from "sysctl -a | grep sysv" ?
regards, tom lane
Chris Mair wrote: > > I have OS X tiger with all the updates: > > > > uname -r > > 8.8.0 > > > > Here is what I get when I try to initdb on a freshly compiled 8.2: > > > > selecting default max_connections ... 10 > > selecting default shared_buffers/max_fsm_pages ... 400kB/20000 > > 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=2, size=1646592, 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 1646592 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. > > child process exited with exit code 1 > > > > Works for me :| > (see initdb output below)... > > > > > I read the documentation > > (http://www.postgresql.org/docs/8.2/static/kernel-resources.html) and > > added the appropriate items to /etc/sysctl.conf, and I rebooted for it > > to take effect. > > > > cat /etc/sysctl.conf > > kern.sysv.shmmax=4194304 > > kern.sysv.shmmin=1 > > kern.sysv.shmmni=32 > > kern.sysv.shmseg=8 > > kern.sysv.shmall=1024 > > Can you check whether the settings worked? Do: > > ibook:~ chris$ sysctl -a | grep shm > kern.sysv.shmmax: 4194304 > kern.sysv.shmmin: 1 > kern.sysv.shmmni: 32 > kern.sysv.shmseg: 8 > kern.sysv.shmall: 1024 > > Bye, > Chris. Here is what I get: sysctl -a | grep shm kern.sysv.shmmax: 4194304 kern.sysv.shmmin: 1 kern.sysv.shmmni: 32 kern.sysv.shmseg: 8 kern.sysv.shmall: 1024 This is very strange as I just updated OS X with the latest updates and then compiled and installed 8.2. I have used OS X Tiger and postgresql 8.1 compiled from source with no problem.
Karen Hill wrote: > I have OS X tiger with all the updates: > > uname -r > 8.8.0 > > Here is what I get when I try to initdb on a freshly compiled 8.2: > > selecting default max_connections ... 10 > selecting default shared_buffers/max_fsm_pages ... 400kB/20000 > 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=2, size=1646592, 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 1646592 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. > child process exited with exit code 1 > do you have another copy of postgresql running when you run initdb? -- Shane Ambler pgSQL@007Marketing.com Get Sheeky @ http://Sheeky.Biz
Tom Lane wrote: > "Karen Hill" <karen_hill22@yahoo.com> writes: > > I still get the error when I initdb. OS X and PostgreSQL has worked > > before for me, compiled from the source. > > Works for me. What do you get from "sysctl -a | grep sysv" ? > sysctl -a | grep sysv kern.sysv.shmmax: 4194304 kern.sysv.shmmin: 1 kern.sysv.shmmni: 32 kern.sysv.shmseg: 8 kern.sysv.shmall: 1024 kern.sysv.semmni: 87381 kern.sysv.semmns: 87381 kern.sysv.semmnu: 87381 kern.sysv.semmsl: 87381 kern.sysv.semume: 10
> and > added the appropriate items to /etc/sysctl.conf 1) The location may be out of date. Don't add to /etc/sysctl.conf; edit the values already in /etc/rc. Where you set these values has shifted around somewhat in OS X releases. I know that sysctl didn't work in 10.3. I know that rc works in 10.4. 2) The values are out of date. All you're doing with those values is re-specifying the OS X defaults. With 8.2, IIRC postgres defaults to using more memory (the old default was extremely frugal), so out of the box you may need to increase those values rather than only having to increase the OS X values if you increased the postgres values. Just tack an extra zero onto the end of shmmax and shmall and postgres will work with its default values. If you want to increase postgres memory, you may have to revisit these values. 3) The changes don't take effect until reboot, and often an OS X update will reset them so you have to be prepared to re-edit /etc/rc. Finally, the error message you're getting doesn't indicate that postgres is actually requesting much memory. I suspect that you may have something else running on your system which is using SysV shared memory. Nothing to worry about, but something to be aware of when trying to match /etc/rc shm values to postgres settings. -- Scott Ribe scott_ribe@killerbytes.com http://www.killerbytes.com/ (303) 722-0567 voice
Scott Ribe <scott_ribe@killerbytes.com> writes:
> Finally, the error message you're getting doesn't indicate that postgres is
> actually requesting much memory. I suspect that you may have something else
> running on your system which is using SysV shared memory.
Recent versions of OS X have ipcs, so you could try "sudo ipcs -m" to
find out about that.
regards, tom lane
I've seen this error on systems that don't realize they have Apple Remote Desktop installed which has its own copy of Postgres - you may be running a copy and not know it. On Dec 28, 2006, at 11:04 AM, Tom Lane wrote: > Scott Ribe <scott_ribe@killerbytes.com> writes: >> Finally, the error message you're getting doesn't indicate that >> postgres is >> actually requesting much memory. I suspect that you may have >> something else >> running on your system which is using SysV shared memory. > > Recent versions of OS X have ipcs, so you could try "sudo ipcs -m" to > find out about that. > > regards, tom lane > > ---------------------------(end of > broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org/
On Thu, Dec 28, 2006 at 09:11:24AM -0700, Scott Ribe wrote: > > and > > added the appropriate items to /etc/sysctl.conf > > 1) The location may be out of date. Don't add to /etc/sysctl.conf; edit the > values already in /etc/rc. Where you set these values has shifted around > somewhat in OS X releases. I know that sysctl didn't work in 10.3. I know > that rc works in 10.4. That location is not out of date. Use /etc/sysctl.conf instead of /etc/rc for 10.4 (my boxes are at 10.4.8). /etc/rc is more likely to be overwritten by system updates, and that file being overwritten has caused some failures for buildfarm member jackal. /etc/rc is what causes the values from /etc/sysctl.conf to be read in and used. Some values, such as the shm-related values are specified in the default /etc/rc after /etc/sysctl.conf is parsed up by /etc/rc and applied, but in 10.4 the kern.sysv.shm* values can only be set once. > 2) The values are out of date. All you're doing with those values is > re-specifying the OS X defaults. With 8.2, IIRC postgres defaults to using > more memory (the old default was extremely frugal), so out of the box you > may need to increase those values rather than only having to increase the OS > X values if you increased the postgres values. Just tack an extra zero onto > the end of shmmax and shmall and postgres will work with its default values. > If you want to increase postgres memory, you may have to revisit these > values. jackal has the following entries in /etc/sysctl.conf kern.sysv.shmmax=167772160 kern.sysv.shmmin=1 kern.sysv.shmmni=64 kern.sysv.shmseg=16 kern.sysv.shmall=65536 kern.maxproc=2048 kern.maxprocperuid=512 > 3) The changes don't take effect until reboot, and often an OS X update will > reset them so you have to be prepared to re-edit /etc/rc. > > Finally, the error message you're getting doesn't indicate that postgres is > actually requesting much memory. I suspect that you may have something else > running on your system which is using SysV shared memory. Nothing to worry > about, but something to be aware of when trying to match /etc/rc shm values > to postgres settings. I'd have to check my logs to be certain, but that is the error I remember getting on jackal when HEAD's memory requirements increased. Postgres buildfarm runs are the only thing that uses shared memory that normally run on jackal. -- Seneca tentra@gmail.com
> /etc/rc is what causes the values from /etc/sysctl.conf to be read in > and used. Some values, such as the shm-related values are specified in > the default /etc/rc after /etc/sysctl.conf is parsed up by /etc/rc and > applied, but in 10.4 the kern.sysv.shm* values can only be set once. Do you know when this behavior was introduced? -- Scott Ribe scott_ribe@killerbytes.com http://www.killerbytes.com/ (303) 722-0567 voice
On Tue, Jan 02, 2007 at 10:12:56AM -0700, Scott Ribe wrote: > > /etc/rc is what causes the values from /etc/sysctl.conf to be read in > > and used. Some values, such as the shm-related values are specified in > > the default /etc/rc after /etc/sysctl.conf is parsed up by /etc/rc and > > applied, but in 10.4 the kern.sysv.shm* values can only be set once. > > Do you know when this behavior was introduced? No, I've only dealt with 10.4. From what I've read Apple changes shm configuration methods every couple 10.X or so. Older versions, such as 10.2, used other files. But for 10.4 (possibly also 10.3) you have to place the configuration for shmmax, shmmin, shmmni, shmseg, and shmall in /etc/sysctl.conf or somewhere in the boot scripts before OS X sets them. -- Seneca tentra@gmail.com
Seneca Cunningham <tentra@gmail.com> writes: > No, I've only dealt with 10.4. From what I've read Apple changes shm > configuration methods every couple 10.X or so. Yeah, they've changed the behavior at least three times :-(. According to our notes at http://www.postgresql.org/docs/8.2/static/kernel-resources.html the current configuration file layout was introduced at 10.3.9, but sometime later than that they changed the implementation in ways that broke a lot of people's sysctl.conf files (ignoring the settings if SHMMAX isn't exactly a multiple of 4K was one particularly unpleasant and stupid change). There was a period where we didn't know about that restriction and the must-set-all-five rule and consequently came up with a lot of cargo-cult pseudo-science about what worked in 10.4 and what didn't. But I believe the info given on the page above is complete and accurate. Until Apple changes it again ... regards, tom lane