could not create shared memory segment

[bevil]

Hi all

I recently reformatted my SSD to get rid of an unneeded (Windows ) partition on my MacBook Pro retina.

I also updated to Mac OS X 10.9.

I have several Servoy installs, and so far two work just fine (one in Sybase, one in Postgres)

However one of the important ones that is in current development fails to load with the following error:

FATAL: could not create shared memory segment: Invalid argument
DETAIL: Failed system call was shmget(key=5432001, size=289120256, 03600).
HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 289120256 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for.
The PostgreSQL documentation contains more information about shared memory configuration.

Anyone seen this before? (I have and it was a permissions issue - but I don't think it is this time).

Thanks

Bevil

[ptalbot]

You've deleted the wrong partition!

[bevil]

Haha..

Yeah, I could keep the partition and run Servoy in that and lose EVERYTHING ELSE (have you windows guys got 16 bit printing yet? I have an Epson Stylus Pro 9900 - Mac (MacBook Pro) does 16bit prints of 2GB tiff files without hesitation. My pcs couldn't print 2GB tiffs even in 8 bit)...

Or I could keep the Mac partition - run my 485 apps, have 16 bit printing, keep my non glitchy - latent audio, and lose my shared memory segment in Postgres - which used to work..

I think I know which way I am going to keep the machine running....

Thanks Patrick..

[ptalbot]

Depends what your priorities are... YMMV
Java on Windows is a LOT more reliable... Mac OS X + Java is an (oxy)moron to say the least.
Don't thank me, thank Apple and Oracle both

[ROCLASI]

Hi Bevil,

PostgreSQL uses the OS's shared memory and pre-9.3 this requirement was set pretty high to be able to launch. Installers like the one from EnterpriseDB always check for the system shared memory settings (in /etc/sysctl.conf) and when needed would adjust them before it would install PostgreSQL (requires a reboot before you can continue install Pg).
Also Mac OS X sets those settings pretty low by default.

So my suggestion is to re-install PostgreSQL using the EDB installer (choose the 'plain' PostgreSQL installer) and perhaps even upgrade to version 9.3.x. Or else change the shared memory settings manually, just be aware that the amount of connections defined in postgresql.conf and other RAM related settings in there do influence the minimum values you need to set in sysctl.conf (apart from what your system has available of course..).

Hope this helps.

[bevil]

Thank you Robert. I will try the download and reinstall.

Presumably I can install Postgres into my Servoy application_server directory, and leave my databases directory as is?

I have just opened another Servoy developer solution - which has also just gone through this same migration - and Postgres works fine.

The version that DOES run is PostgreSQL 8.4.3 (on i386-apple-darwin, compiled by GCC i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5370), 32-bit). It was part of a Servoy 6.07 install

The version that does not run - with the error above is part of a Servoy 7.3 install.

If that makes any difference.

[ROCLASI]

Presumably I can install Postgres into my Servoy application_server directory, and leave my databases directory as is?

Actually the EDB installer will install the binary in /Library/PostgreSQL/<versionnumber>/bin and the database directory is /Library/PostgreSQL/<versionnumber>/data.
(As you can see you can install different versions next to each other like this).

I have just opened another Servoy developer solution - which has also just gone through this same migration - and Postgres works fine.

Just be aware you don't have to use the bundled PostgreSQL version of 7.3 when you upgrade, you can still use the old version, just copy the binary and database folders over (when still on the same OS).

Hope this helps.