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

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:

> 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.
        regards, tom lane