Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x

From: Roberth Andersson <roberth(at)jump-gate(dot)com>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x
Date: 1999-07-31 16:30:53
Message-ID: 4.1.19990731183041.009ca810@jump-gate.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 11:55 1999-07-31 -0400, you wrote:
>Roberth Andersson <roberth(at)jump-gate(dot)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

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-07-31 16:50:37 Re: Selectivity of "=" (Re: [HACKERS] Index not used on simple se lect)
Previous Message Roberth Andersson 1999-07-31 16:22:20 Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x