Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x - Mailing list pgsql-hackers

From Roberth Andersson
Subject Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x
Date
Msg-id 4.1.19990731183041.009ca810@jump-gate.com
Whole thread Raw
List pgsql-hackers
At 11:55 1999-07-31 -0400, you wrote:
>Roberth Andersson <roberth@jump-gate.com> writes:
>> BUT when I wrote "postmaster -i" I got a big
>> problem which I have never got ever before and I don't know why. Here is
>> the error message from postmaster ->
>
>> IpcMemoryCreate: shmget failed (Invalid argument) key=5432001,
>> size=1063936, permission=600
>> FATAL 1:  ShmemCreate: cannot create region
>
>The kernel error message ("Invalid argument", here) is often very
>unhelpful when dealing with shared memory and semaphore operations :-(
>I will bet that the real problem is that your kernel is configured
>not to allow shared mem regions bigger than 1 megabyte --- but could
>it say "Request too big", or some such?  Nooo...
>Postgres 6.5 defaults to wanting a shmem region just over a meg, whereas
>6.4 was just under IIRC, so this problem will bite anyone who has the
>fairly common kernel parameter setting SHMEMMAX = 1meg.
>If that's the problem, you can either reconfigure your kernel with a
>larger SHMEMMAX setting, or start Postgres with smaller-than-default
>limits on number of buffers and backends.  I'd try -N 16 for starters.
>Another possibility is that you are running into a kernel limit on the
>total amount of shared memory, not the size of this individual chunk.
>You say:

Thanks Tom

Is it possible to find how big it is right now without touching the kernel
source codes ?  I tried to search also for SHMEMMAX in the source codes,
but found nothing.

I am going to try to start up Postgres later today with your suggested
parameter -N 16 and see whats happends.

>> This is what I get when I write ipcs ->
>> Message Queues:
>> T           ID          KEY        MODE    OWNER    GROUP
>
>> Shared Memory:
>> T           ID          KEY        MODE    OWNER    GROUP
>> m       196608      5432210 --rwa------ postgres     user
>> m       196609      5432201 --rw------- postgres     user
>> m       983042      5432207 --rw------- postgres     user
>> m      1376259      5432010 --rwa------ postgres postgres
>> m       131076      5432001 --rw------- postgres     user
>> m       786437      5432007 --rw------- postgres postgres
>
>> Semaphores:
>> T           ID          KEY        MODE    OWNER    GROUP
>
>If you do not have a postmaster running then those postgres-owned shared
>memory segments should not be there; they must be left over from some
>old run where the postmaster crashed without releasing 'em :-(.  They
>could be causing the kernel to decide it's given out too much shared
>memory.  Use ipcclean to get rid of them.

I tried to do that and it worked just fine the first time, and after that I
wrote "ipcs" to get a statistical if it really was cleaned or not, but I
got this ->

Message Queues:
T           ID          KEY        MODE    OWNER    GROUP

Shared Memory:
T           ID          KEY        MODE    OWNER    GROUP
m      1376259            0 --rwa------ postgres postgres
m       131076            0 --rw------- postgres     user
m       786437            0 --rw------- postgres postgres

Semaphores:
T           ID          KEY        MODE    OWNER    GROUP

Now I tried to use "ipcclean" once again, and I am always getting these
errors ->

ipcrm: shmid(1376259): : Invalid argument
ipcrm: shmid(131076): : Invalid argument
ipcrm: shmid(786437): : Invalid argument

I have no idea why, except maybe this could be something that is left over
since old and now the system doesn't know how to remove this Postgres stuff.

If anyone have any clue about what I can do, please let me know, I would
appreciate it a lot.

Sincerely 


pgsql-hackers by date:

Previous
From: Roberth Andersson
Date:
Subject: Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x
Next
From: Bruce Momjian
Date:
Subject: Re: Selectivity of "=" (Re: [HACKERS] Index not used on simple se lect)