Thread: shared memory after server kill

I have a problem that I can't understand.

I am using macosx, pg 7.4.3.  I had a server running and working.  I
tried to bring the server down with 'pg_ctl stop', which failed (server
running on localhost).  I then (timidly) killed the postmaster process.

When I tried to bring the server back up, I got an error similar to:

  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.

I have 4 Gb of memory, with approximately 2.6 Gb available (via top)
and a vast swap.  What is going on?

Thanks,
Sean

I forgot to mention--I then cleaned the installation (removed the
installed root directory), reinstalled, did initdb and got the same
result with the initdb call.

Sean

On Aug 5, 2004, at 6:34 AM, Sean Davis wrote:

> I have a problem that I can't understand.
>
> I am using macosx, pg 7.4.3.  I had a server running and working.  I
> tried to bring the server down with 'pg_ctl stop', which failed
> (server running on localhost).  I then (timidly) killed the postmaster
> process.
>
> When I tried to bring the server back up, I got an error similar to:
>
>  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.
>
> I have 4 Gb of memory, with approximately 2.6 Gb available (via top)
> and a vast swap.  What is going on?
>
> Thanks,
> Sean
>
>
> ---------------------------(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

Sean Davis wrote:
 > I am using macosx, pg 7.4.3.  I had a server running and working.  I
 > tried to bring the server down with 'pg_ctl stop', which failed (server
 > running on localhost).  I then (timidly) killed the postmaster process.
 >
 > When I tried to bring the server back up, I got an error similar to:
 >
 >   FATAL:  could not create shared memory segment: Cannot allocate memory
 > DETAIL:  Failed system call was shmget(key=1, size=1081344, 03600).
 > [...]
 > I have 4 Gb of memory, with approximately 2.6 Gb available (via top)
 > and a vast swap.  What is going on?

When you kill the postmaster process forcibly, it doesn't
release the shared memory segments that it had allocated.

Use the "ipcs" command to list all currently allocated
shared memory segments, and use "ipcrm" to remove them.
I've once written a small shell script which basically
does it (I've only tested it on FreeBSD, but Mac OS X
should be similar enough):

#!/bin/sh -
ipcs | awk '($1=="m"){print $2}' | xargs -n 1 -t ipcrm -m

Of course, you can also solve the problem the Windows way
(i.e. reboot).  ;-)

Best regards
   Oliver

--
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

With Perl you can manipulate text, interact with programs, talk over
networks, drive Web pages, perform arbitrary precision arithmetic,
and write programs that look like Snoopy swearing.

Oliver Fromme <olli@lurza.secnetix.de> writes:
> When you kill the postmaster process forcibly, it doesn't
> release the shared memory segments that it had allocated.

> Use the "ipcs" command to list all currently allocated
> shared memory segments, and use "ipcrm" to remove them.

For some benighted reason, OS X doesn't provide either of those commands
(last I looked anyway).  AFAIK the only way to get rid of an unreleased
shmem segment in OS X is to reboot; there is no manual access to the
shared memory status.

Combine this problem with the fact that OS X's default limit on shmem
size is very small (not enough to allow two reasonable-sized shmem
segments), and you end up with the conclusion that kill -9'ing the
postmaster is an even worse idea on OS X than it is on other systems.
Next time use "kill -QUIT" if you want an emergency postmaster shutdown.
Or try "pg_ctl stop -m fast".

(But I think the real beginner mistake was to try to solve a problem by
killing the postmaster, rather than whichever child process was wedged.
The postmaster process is almost never the direct source of a user-visible
problem.)

            regards, tom lane