Re: icps, shmmax and shmall - Shared Memory tuning - Mailing list pgsql-general

From Tom Lane
Subject Re: icps, shmmax and shmall - Shared Memory tuning
Date
Msg-id 27598.1019846792@sss.pgh.pa.us
Whole thread Raw
In response to icps, shmmax and shmall - Shared Memory tuning  (dorian dorian <dorian37076@yahoo.com>)
Responses Re: icps, shmmax and shmall - Shared Memory tuning
List pgsql-general
dorian dorian <dorian37076@yahoo.com> writes:
> Apr 26 09:43:16 mito logger: IpcMemoryCreate:
> shmget(key=5432001, size=137175040, 03600) failed: Invalid argument

> ------ Shared Memory Segments --------
> key       shmid     owner     perms     bytes
> nattch    status
> 0x0052e2c1 98307     postgres  600       137175040 28

This is very strange.  The postmaster should have re-used the existing
shmem segment, rather than trying to create a new one as it's evidently
doing.  Or, if it didn't do that, it should've tried to create a new
segment with a different key, not re-use the conflicting key.  There's
some kind of bug here.  Are you up for tracing through IpcMemoryCreate
with a debugger to see what's going wrong?

If you just want to get going again, you can remove that segment with
ipcrm (I think "ipcrm shm 98307" is the syntax to use on Linux) and
then the postmaster should start.  But it would be useful to understand
the failure mode so we can fix it.

FWIW, I do not see any comparable problem on rh7.2 (2.4.7-10 kernel) ---
the postmaster restarts perfectly cleanly after doing a kill -9 on one
of its children.

            regards, tom lane

pgsql-general by date:

Previous
From: Michael Loftis
Date:
Subject: Re: intel vs amd benchmark for pg server
Next
From: webmaster
Date:
Subject: delete column