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