OSX 10.3.7 broke Postgresql 8.0.0b5?

Ok, I got postgres to start...
I used these settings.

kern.sysv.shmmax: 167772160
kern.sysv.shmmin: 1
kern.sysv.shmmni: 32
kern.sysv.shmseg: 8
kern.sysv.shmall: 65536
kern.sysv.semmni: 87381
kern.sysv.semmns: 87381
kern.sysv.semmnu: 87381
kern.sysv.semmsl: 87381
kern.sysv.semume: 10

On Dec 17, 2004, at 3:41 PM, Jerry LeVan wrote:

Jerry LeVan <jerry.levan@eku.edu> writes:

Ok, I got postgres to start...
I used these settings.

FWIW, I just updated to 10.3.7 from 10.3.6 and compared the kern.sysv.*
sysctl settings before and after. I see no indication that the default
values have changed.

regards, tom lane

Well, what might be some good settings for a smallish db with
the default configuration?

Jerry

On Dec 17, 2004, at 5:40 PM, Tom Lane wrote:

I'm getting the same error now too, although postgres was running
without problem this morning (I updated the OS yesterday). OS X 10.3.7
Server, PostgreSQL 8.0RC1. Basically, I did a pg_dump, stopped the
server and then tried to start it again.

Any ideas?

On Dec 17, 2004, at 2:41 PM, Jerry LeVan wrote:

Timothy Perrigo <tperrigo@wernervas.com> writes:

I'm getting the same error now too, although postgres was running
without problem this morning (I updated the OS yesterday). OS X 10.3.7
Server, PostgreSQL 8.0RC1. Basically, I did a pg_dump, stopped the
server and then tried to start it again.

Fascinating. As far as I can tell on my machine, 10.3.7 did not change
the kernel IPC limits. So if it's not working for you guys that would
suggest that 10.3.7 added some new background usage of IPC resources,
which in combination with the PG postmaster exceeds the same-as-it-ever-
was kernel limit.

If ipcs worked then we'd have some chance of investigating this, but OS
X doesn't provide ipcs. (Thank you Apple ... not)

FWIW, my installation of PG on OS X defaults to
max_connections = 50
shared_buffers = 300
because values higher than that exceed the default kernel limits.

It looks like yours has 100/1000 --- did you hand-modify that? Or maybe
you hand-modified the kernel limits? Another possible explanation is
that the 10.3.7 update overwrote any local changes you'd made to the IPC
limits.

regards, tom lane

On Dec 17, 2004, at 11:10 PM, Tom Lane wrote:

Fascinating. As far as I can tell on my machine, 10.3.7 did not change
the kernel IPC limits. So if it's not working for you guys that would
suggest that 10.3.7 added some new background usage of IPC resources,
which in combination with the PG postmaster exceeds the
same-as-it-ever-
was kernel limit.

If ipcs worked then we'd have some chance of investigating this, but OS
X doesn't provide ipcs. (Thank you Apple ... not)

FWIW, my installation of PG on OS X defaults to
max_connections = 50
shared_buffers = 300
because values higher than that exceed the default kernel limits.

It looks like yours has 100/1000 --- did you hand-modify that? Or
maybe
you hand-modified the kernel limits? Another possible explanation is
that the 10.3.7 update overwrote any local changes you'd made to the
IPC
limits.

regards, tom lane

I dropped the shared_buffers from 300 (the number determined by initdb)
to 200 and I am now able to start the server.

Tim

It looks like yours has 100/1000 --- did you hand-modify that? Or maybe
you hand-modified the kernel limits? Another possible explanation is
that the 10.3.7 update overwrote any local changes you'd made to the IPC
limits.

All the recent OS X .x updates have replaced /etc/rc. For all I know they
may always have done so, but of course prior to 10.3 we didn't have to
modify /etc/rc directly.

--
Scott Ribe
scott_ribe@killerbytes.com
http://www.killerbytes.com/
(303) 665-7007 voice

Scott Ribe <scott_ribe@killerbytes.com> writes:

It looks like yours has 100/1000 --- did you hand-modify that? Or maybe
you hand-modified the kernel limits? Another possible explanation is
that the 10.3.7 update overwrote any local changes you'd made to the IPC
limits.

All the recent OS X .x updates have replaced /etc/rc. For all I know they
may always have done so, but of course prior to 10.3 we didn't have to
modify /etc/rc directly.

Bingo. So I didn't see any change in behavior, because I hadn't edited
/etc/rc on my machine; the complainants are probably those who had
edited /etc/rc to raise the kern.sysv limits.

I'll add something to the Admin Guide pointing out that OS X updates are
likely to overwrite any manual changes to /etc/rc.

regards, tom lane

On 12/18/04 11:03 AM, "Scott Ribe" <scott_ribe@killerbytes.com> wrote:

All the recent OS X .x updates have replaced /etc/rc. For all I know they
may always have done so, but of course prior to 10.3 we didn't have to
modify /etc/rc directly.

You shouldn't be modifying /etc/rc directly anyway. Create a startup script
in /Library/StartupItems, or /etc/mach_init.d. I believe the latter is new
with 10.3 and is now the preferred method. Granted, modifying /etc/rc is a
lot easier, but you pay for it later when an update wipes out your changes
and you beat your head against the wall trying to find the problem.

Wes

Wes <wespvp@syntegra.com> writes:

On 12/18/04 11:03 AM, "Scott Ribe" <scott_ribe@killerbytes.com> wrote:

All the recent OS X .x updates have replaced /etc/rc. For all I know they
may always have done so, but of course prior to 10.3 we didn't have to
modify /etc/rc directly.

You shouldn't be modifying /etc/rc directly anyway.

*Tell* us about it. Apple used to have a more reasonable method for
setting the SysV IPC parameters, but AFAICT you have to hack /etc/rc.d
now; anyplace else runs too late to affect them.

regards, tom lane

You shouldn't be modifying /etc/rc directly anyway. Create a startup script
in /Library/StartupItems, or /etc/mach_init.d. I believe the latter is new
with 10.3 and is now the preferred method. Granted, modifying /etc/rc is a
lot easier, but you pay for it later when an update wipes out your changes
and you beat your head against the wall trying to find the problem.

Startup items can no longer change the sysv kernel settings. I forget
whether that is a 10.2 change, or a 10.3 change, but setting them in a
startup item has no effect and hasn't for a pretty long time.

I was not aware of /etc/mach_init.d, a quick glance at the docs make it
obvious that it runs earlier than SystemStarter, looking at /etc/rc shows
that it runs not that much later than the normal settings of the sysv
parameters. Are you sure changing sysv kernel parameters at that point will
work?

--
Scott Ribe
scott_ribe@killerbytes.com
http://www.killerbytes.com/
(303) 665-7007 voice