Thread: OSX 10.3.7 broke Postgresql 8.0.0b5?

OSX 10.3.7 broke Postgresql 8.0.0b5?

From
Jerry LeVan
Date:
I *think* the 10.3.7 upgrade broke my postgresql implementation...

I am getting this error at startup.

FATAL:  could not create shared memory segment: Cannot allocate memory
DETAIL:  Failed system call was shmget(key=5432001, size=10403840,
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 10403840 bytes), reduce PostgreSQL's
shared_buffers parameter (currently 1000) and/or its max_connections
parameter (currently 100).
         The PostgreSQL documentation contains more information about
shared memory configuration.

The first time I noticed the problem I found that the shmmax was set low
at a bit more than 4MB ( perhaps the upgrade replaced /etc/rc ).

I increased the shmmax to about 64MB and still get the same error.

Here are the current kernel settings

kern.sysv.shmmax: 67108864
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

Do I need to increase anything else?

I am on the digest, if someone knows the answer please CC to me also...

Jerry


Re: OSX 10.3.7 broke Postgresql 8.0.0b5?

From
Jerry LeVan
Date:
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:

> I *think* the 10.3.7 upgrade broke my postgresql implementation...
>
> I am getting this error at startup.
>
> FATAL:  could not create shared memory segment: Cannot allocate memory
> DETAIL:  Failed system call was shmget(key=5432001, size=10403840,
> 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 10403840 bytes), reduce PostgreSQL's
> shared_buffers parameter (currently 1000) and/or its max_connections
> parameter (currently 100).
>         The PostgreSQL documentation contains more information about
> shared memory configuration.
>
> The first time I noticed the problem I found that the shmmax was set
> low
> at a bit more than 4MB ( perhaps the upgrade replaced /etc/rc ).
>
> I increased the shmmax to about 64MB and still get the same error.
>
> Here are the current kernel settings
>
> kern.sysv.shmmax: 67108864
> 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
>
> Do I need to increase anything else?
>
> I am on the digest, if someone knows the answer please CC to me also...
>
> Jerry
>


Re: OSX 10.3.7 broke Postgresql 8.0.0b5?

From
Tom Lane
Date:
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

Re: OSX 10.3.7 broke Postgresql 8.0.0b5?

From
Jerry LeVan
Date:
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:

> 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
>


Re: OSX 10.3.7 broke Postgresql 8.0.0b5?

From
Timothy Perrigo
Date:
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:

> I *think* the 10.3.7 upgrade broke my postgresql implementation...
>
> I am getting this error at startup.
>
> FATAL:  could not create shared memory segment: Cannot allocate memory
> DETAIL:  Failed system call was shmget(key=5432001, size=10403840,
> 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 10403840 bytes), reduce PostgreSQL's
> shared_buffers parameter (currently 1000) and/or its max_connections
> parameter (currently 100).
>         The PostgreSQL documentation contains more information about
> shared memory configuration.
>
> The first time I noticed the problem I found that the shmmax was set
> low
> at a bit more than 4MB ( perhaps the upgrade replaced /etc/rc ).
>
> I increased the shmmax to about 64MB and still get the same error.
>
> Here are the current kernel settings
>
> kern.sysv.shmmax: 67108864
> 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
>
> Do I need to increase anything else?
>
> I am on the digest, if someone knows the answer please CC to me also...
>
> Jerry
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 8: explain analyze is your friend
>


Re: OSX 10.3.7 broke Postgresql 8.0.0b5?

From
Tom Lane
Date:
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

Re: OSX 10.3.7 broke Postgresql 8.0.0b5?

From
Timothy Perrigo
Date:
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


Re: OSX 10.3.7 broke Postgresql 8.0.0b5?

From
Scott Ribe
Date:
> 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



Re: OSX 10.3.7 broke Postgresql 8.0.0b5?

From
Tom Lane
Date:
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

Re: OSX 10.3.7 broke Postgresql 8.0.0b5?

From
Wes
Date:
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


Re: OSX 10.3.7 broke Postgresql 8.0.0b5?

From
Tom Lane
Date:
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

Re: OSX 10.3.7 broke Postgresql 8.0.0b5?

From
Scott Ribe
Date:
> 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