shmget fails on OS X with proper settings

Hi to the list, its my first post.

I was previous running postgres 8.2.1 on my OS X 10.4.9 laptop with no
problems.
After I sent it to apple care, I found that I can no longer start the
postmaster daemon. When I try, I receive the standard shmget failed
error message:

FATAL: could not create shared memory segment: Cannot allocate memory
DETAIL: Failed system call was shmget(key=5432001, size=4112384, 03600).
HINT: This error usually means that PostgreSQL's request for a shared
memory segment exceeded available memory or swap space. To reduce the
request size (currently 4112384 bytes), reduce PostgreSQL's
shared_buffers parameter (currently 300) and/or its max_connections
parameter (currently 30).

I get this error with either the settings recommended on the kernel
resources page:

kern.sysv.shmmax=4194304
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024

And I also get it when i set kern.sysv.shmmax=12582912

After making all these changed rebooting doesn't fix anything.

Has anyone ran into this problem, or has any idea as to why this would
start to fail so suddenly?

Thanks,
Chris

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

On 5/6/07, Martin Gainty <mgainty@hotmail.com> wrote:

if you're getting memory errors then a guess would be did they take out any
memory out of your machine or perhaps did they change your memory cache
parameters???
Martin
This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed. If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy. Thank you.

----- Original Message -----
From: "Christopher S Martin" <martin.christopher.s@gmail.com>
To: <pgsql-general@postgresql.org>
Sent: Sunday, May 06, 2007 3:07 PM
Subject: [GENERAL] shmget fails on OS X with proper settings

Hi to the list, its my first post.

I was previous running postgres 8.2.1 on my OS X 10.4.9 laptop with no
problems.
After I sent it to apple care, I found that I can no longer start the
postmaster daemon. When I try, I receive the standard shmget failed
error message:

FATAL: could not create shared memory segment: Cannot allocate memory
DETAIL: Failed system call was shmget(key=5432001, size=4112384, 03600).
HINT: This error usually means that PostgreSQL's request for a shared
memory segment exceeded available memory or swap space. To reduce the
request size (currently 4112384 bytes), reduce PostgreSQL's
shared_buffers parameter (currently 300) and/or its max_connections
parameter (currently 30).

I get this error with either the settings recommended on the kernel
resources page:

kern.sysv.shmmax=4194304
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024

And I also get it when i set kern.sysv.shmmax=12582912

After making all these changed rebooting doesn't fix anything.

Has anyone ran into this problem, or has any idea as to why this would
start to fail so suddenly?

Thanks,
Chris

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

On 5/7/07, Christopher S Martin <martin.christopher.s@gmail.com> wrote:

Martin:

They didn't take any memory out of the machine. AS for memory cache
parameters, I'm don't know about that. How would I go checking for
that type of thing?

Thanks,
Chris

On 5/6/07, Martin Gainty <mgainty@hotmail.com> wrote:

if you're getting memory errors then a guess would be did they take out

any

memory out of your machine or perhaps did they change your memory cache
parameters???
Martin
This email message and any files transmitted with it contain

confidential

information intended only for the person(s) to whom this email message

is

addressed. If you have received this email message in error, please

notify

the sender immediately by telephone or email and destroy the original
message without making a copy. Thank you.

----- Original Message -----
From: "Christopher S Martin" <martin.christopher.s@gmail.com>
To: <pgsql-general@postgresql.org>
Sent: Sunday, May 06, 2007 3:07 PM
Subject: [GENERAL] shmget fails on OS X with proper settings

Hi to the list, its my first post.

I was previous running postgres 8.2.1 on my OS X 10.4.9 laptop with no
problems.
After I sent it to apple care, I found that I can no longer start the
postmaster daemon. When I try, I receive the standard shmget failed
error message:

FATAL: could not create shared memory segment: Cannot allocate memory
DETAIL: Failed system call was shmget(key=5432001, size=4112384,

03600).

HINT: This error usually means that PostgreSQL's request for a shared
memory segment exceeded available memory or swap space. To reduce the
request size (currently 4112384 bytes), reduce PostgreSQL's
shared_buffers parameter (currently 300) and/or its max_connections
parameter (currently 30).

I get this error with either the settings recommended on the kernel
resources page:

kern.sysv.shmmax=4194304
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024

And I also get it when i set kern.sysv.shmmax=12582912

After making all these changed rebooting doesn't fix anything.

Has anyone ran into this problem, or has any idea as to why this would
start to fail so suddenly?

Thanks,
Chris

---------------------------(end of

broadcast)---------------------------

TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On 5/7/07, Prashant Ranjalkar <prashant.ranjalkar@gmail.com> wrote:

Hello,

The previously running postmaster process might not closed properly and
released the kernel's memory.
Check for any process running on the server if it exists then kill the
process.here due to unrelease of kernel's memory and while booting the
process is not releasing shared memory hence leading to problems.

regards
Prashant Ranjalkar
EnterpriseDB

On 5/7/07, Christopher S Martin < martin.christopher.s@gmail.com> wrote:

Martin:

They didn't take any memory out of the machine. AS for memory cache
parameters, I'm don't know about that. How would I go checking for
that type of thing?

Thanks,
Chris

On 5/6/07, Martin Gainty <mgainty@hotmail.com > wrote:

if you're getting memory errors then a guess would be did they take out

any

memory out of your machine or perhaps did they change your memory cache
parameters???
Martin
This email message and any files transmitted with it contain

confidential

information intended only for the person(s) to whom this email message

is

addressed. If you have received this email message in error, please

notify

the sender immediately by telephone or email and destroy the original
message without making a copy. Thank you.

----- Original Message -----
From: "Christopher S Martin" <martin.christopher.s@gmail.com >
To: <pgsql-general@postgresql.org>
Sent: Sunday, May 06, 2007 3:07 PM
Subject: [GENERAL] shmget fails on OS X with proper settings

Hi to the list, its my first post.

I was previous running postgres 8.2.1 on my OS X 10.4.9 laptop with no
problems.
After I sent it to apple care, I found that I can no longer start the
postmaster daemon. When I try, I receive the standard shmget failed
error message:

FATAL: could not create shared memory segment: Cannot allocate memory
DETAIL: Failed system call was shmget(key=5432001, size=4112384,

03600).

HINT: This error usually means that PostgreSQL's request for a shared
memory segment exceeded available memory or swap space. To reduce the
request size (currently 4112384 bytes), reduce PostgreSQL's
shared_buffers parameter (currently 300) and/or its max_connections
parameter (currently 30).

I get this error with either the settings recommended on the kernel
resources page:

kern.sysv.shmmax=4194304
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024

And I also get it when i set kern.sysv.shmmax=12582912

After making all these changed rebooting doesn't fix anything.

Has anyone ran into this problem, or has any idea as to why this would
start to fail so suddenly?

Thanks,
Chris

---------------------------(end of

broadcast)---------------------------

TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

---------------------------(end of

broadcast)---------------------------

TIP 6: explain analyze is your friend

On 5/7/07, Christopher S Martin <martin.christopher.s@gmail.com> wrote:

sysctl -a reveals the following:
kern.sysv.shmmax: 12582912
kern.sysv.shmmin: 1
kern.sysv.shmmni: 32
kern.sysv.shmseg: 8
kern.sysv.shmall: 1024
kern.sysv.semmni: 87381
kern.sysv.semmns: 87381
kern.sysv.semmnu: 87381
kern.sysv.semmsl: 87381
kern.sysv.semume: 10

I am using the sysctl.conf file in /etc to set these values at boot
time, but in that file I only have the following entries:

kern.sysv.shmmax=12582912
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024

When booting up in unix mode to view the output from all the startup
processes, I do notice that it looks like the sysctl values are read
and set twice, not sure if this would affect anything.

I checked the process listing for any other postmaster processes that
could have been left running, but nothing it showing up. I'm using a
LaunchAgent to start postmaster, so it shouldn't be starting on its
own anyway.

On 5/7/07, Prashant Ranjalkar <prashant.ranjalkar@gmail.com> wrote:

Hello,

The previously running postmaster process might not closed properly and
released the kernel's memory.
Check for any process running on the server if it exists then kill the
process.here due to unrelease of kernel's memory and while booting the
process is not releasing shared memory hence leading to problems.

regards
Prashant Ranjalkar
EnterpriseDB

On 5/7/07, Christopher S Martin < martin.christopher.s@gmail.com> wrote:

Martin:

They didn't take any memory out of the machine. AS for memory cache
parameters, I'm don't know about that. How would I go checking for
that type of thing?

Thanks,
Chris

On 5/6/07, Martin Gainty <mgainty@hotmail.com > wrote:

if you're getting memory errors then a guess would be did they take

out

any

memory out of your machine or perhaps did they change your memory

cache

parameters???
Martin
This email message and any files transmitted with it contain

confidential

information intended only for the person(s) to whom this email

message

is

addressed. If you have received this email message in error, please

notify

the sender immediately by telephone or email and destroy the

original

message without making a copy. Thank you.

----- Original Message -----
From: "Christopher S Martin" <martin.christopher.s@gmail.com >
To: <pgsql-general@postgresql.org>
Sent: Sunday, May 06, 2007 3:07 PM
Subject: [GENERAL] shmget fails on OS X with proper settings

Hi to the list, its my first post.

I was previous running postgres 8.2.1 on my OS X 10.4.9 laptop

with no

problems.
After I sent it to apple care, I found that I can no longer start

the

postmaster daemon. When I try, I receive the standard shmget

failed

error message:

FATAL: could not create shared memory segment: Cannot allocate

memory

DETAIL: Failed system call was shmget(key=5432001, size=4112384,

03600).

HINT: This error usually means that PostgreSQL's request for a

shared

memory segment exceeded available memory or swap space. To reduce

the

request size (currently 4112384 bytes), reduce PostgreSQL's
shared_buffers parameter (currently 300) and/or its

max_connections

parameter (currently 30).

I get this error with either the settings recommended on the

kernel

resources page:

kern.sysv.shmmax=4194304
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024

And I also get it when i set kern.sysv.shmmax=12582912

After making all these changed rebooting doesn't fix anything.

Has anyone ran into this problem, or has any idea as to why this

would

start to fail so suddenly?

Thanks,
Chris

---------------------------(end of

broadcast)---------------------------

TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

---------------------------(end of

broadcast)---------------------------

TIP 6: explain analyze is your friend

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On 5/7/07, Prashant Ranjalkar <prashant.ranjalkar@gmail.com> wrote:

Hello,

Please check any .pid file exist in your data directory. If it exists then
postmaster is running and memory is not freed up.
Also check
ipcs -mp

it will give any shared memory allocated segments if any and consuming the
memory.

regards
Prashant Ranjalkar

On 5/7/07, Christopher S Martin <martin.christopher.s@gmail.com > wrote:

sysctl -a reveals the following:
kern.sysv.shmmax: 12582912
kern.sysv.shmmin : 1
kern.sysv.shmmni: 32
kern.sysv.shmseg: 8
kern.sysv.shmall: 1024
kern.sysv.semmni: 87381
kern.sysv.semmns: 87381
kern.sysv.semmnu: 87381
kern.sysv.semmsl: 87381
kern.sysv.semume: 10

I am using the sysctl.conf file in /etc to set these values at boot
time, but in that file I only have the following entries:

kern.sysv.shmmax=12582912
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024

When booting up in unix mode to view the output from all the startup
processes, I do notice that it looks like the sysctl values are read
and set twice, not sure if this would affect anything.

I checked the process listing for any other postmaster processes that
could have been left running, but nothing it showing up. I'm using a
LaunchAgent to start postmaster, so it shouldn't be starting on its
own anyway.

On 5/7/07, Prashant Ranjalkar < prashant.ranjalkar@gmail.com> wrote:

Hello,

The previously running postmaster process might not closed properly and
released the kernel's memory.
Check for any process running on the server if it exists then kill the
process.here due to unrelease of kernel's memory and while booting the
process is not releasing shared memory hence leading to problems.

regards
Prashant Ranjalkar
EnterpriseDB

On 5/7/07, Christopher S Martin < martin.christopher.s@gmail.com> wrote:

Martin:

They didn't take any memory out of the machine. AS for memory cache
parameters, I'm don't know about that. How would I go checking for
that type of thing?

Thanks,
Chris

On 5/6/07, Martin Gainty <mgainty@hotmail.com > wrote:

if you're getting memory errors then a guess would be did they take

out

any

memory out of your machine or perhaps did they change your memory

cache

parameters???
Martin
This email message and any files transmitted with it contain

confidential

information intended only for the person(s) to whom this email

message

is

addressed. If you have received this email message in error, please

notify

the sender immediately by telephone or email and destroy the

original

message without making a copy. Thank you.

----- Original Message -----
From: "Christopher S Martin" < martin.christopher.s@gmail.com >
To: <pgsql-general@postgresql.org>
Sent: Sunday, May 06, 2007 3:07 PM
Subject: [GENERAL] shmget fails on OS X with proper settings

Hi to the list, its my first post.

I was previous running postgres 8.2.1 on my OS X 10.4.9 laptop

with no

problems.
After I sent it to apple care, I found that I can no longer start

the

postmaster daemon. When I try, I receive the standard shmget

failed

error message:

FATAL: could not create shared memory segment: Cannot allocate

memory

DETAIL: Failed system call was shmget(key=5432001, size=4112384,

03600).

HINT: This error usually means that PostgreSQL's request for a

shared

memory segment exceeded available memory or swap space. To reduce

the

request size (currently 4112384 bytes), reduce PostgreSQL's
shared_buffers parameter (currently 300) and/or its

max_connections

parameter (currently 30).

I get this error with either the settings recommended on the

kernel

resources page:

kern.sysv.shmmax=4194304
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024

And I also get it when i set kern.sysv.shmmax=12582912

After making all these changed rebooting doesn't fix anything.

Has anyone ran into this problem, or has any idea as to why this

would

start to fail so suddenly?

Thanks,
Chris

---------------------------(end of

broadcast)---------------------------

TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

---------------------------(end of

broadcast)---------------------------

TIP 6: explain analyze is your friend

---------------------------(end of

broadcast)---------------------------

TIP 6: explain analyze is your friend

On 5/7/07, Christopher S Martin <martin.christopher.s@gmail.com> wrote:

No .pid files found in the data directory.
The ipcs output doesn't list anything owned by the postgres user, or by
root.

Thanks,
Chris

On 5/7/07, Prashant Ranjalkar <prashant.ranjalkar@gmail.com> wrote:

Hello,

Please check any .pid file exist in your data directory. If it exists

then

postmaster is running and memory is not freed up.
Also check
ipcs -mp

it will give any shared memory allocated segments if any and consuming

the

memory.

regards
Prashant Ranjalkar

On 5/7/07, Christopher S Martin <martin.christopher.s@gmail.com > wrote:

sysctl -a reveals the following:
kern.sysv.shmmax: 12582912
kern.sysv.shmmin : 1
kern.sysv.shmmni: 32
kern.sysv.shmseg: 8
kern.sysv.shmall: 1024
kern.sysv.semmni: 87381
kern.sysv.semmns: 87381
kern.sysv.semmnu: 87381
kern.sysv.semmsl: 87381
kern.sysv.semume: 10

I am using the sysctl.conf file in /etc to set these values at boot
time, but in that file I only have the following entries:

kern.sysv.shmmax=12582912
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024

When booting up in unix mode to view the output from all the startup
processes, I do notice that it looks like the sysctl values are read
and set twice, not sure if this would affect anything.

I checked the process listing for any other postmaster processes that
could have been left running, but nothing it showing up. I'm using a
LaunchAgent to start postmaster, so it shouldn't be starting on its
own anyway.

On 5/7/07, Prashant Ranjalkar < prashant.ranjalkar@gmail.com> wrote:

Hello,

The previously running postmaster process might not closed properly

and

released the kernel's memory.
Check for any process running on the server if it exists then kill

the

process.here due to unrelease of kernel's memory and while booting

the

process is not releasing shared memory hence leading to problems.

regards
Prashant Ranjalkar
EnterpriseDB

On 5/7/07, Christopher S Martin < martin.christopher.s@gmail.com>

wrote:

Martin:

They didn't take any memory out of the machine. AS for memory

cache

parameters, I'm don't know about that. How would I go checking

for

that type of thing?

Thanks,
Chris

On 5/6/07, Martin Gainty <mgainty@hotmail.com > wrote:

if you're getting memory errors then a guess would be did they

take

out

any

memory out of your machine or perhaps did they change your

memory

cache

parameters???
Martin
This email message and any files transmitted with it contain

confidential

information intended only for the person(s) to whom this email

message

is

addressed. If you have received this email message in error,

please

notify

the sender immediately by telephone or email and destroy the

original

message without making a copy. Thank you.

----- Original Message -----
From: "Christopher S Martin" < martin.christopher.s@gmail.com >
To: <pgsql-general@postgresql.org>
Sent: Sunday, May 06, 2007 3:07 PM
Subject: [GENERAL] shmget fails on OS X with proper settings

Hi to the list, its my first post.

I was previous running postgres 8.2.1 on my OS X 10.4.9 laptop

with no

problems.
After I sent it to apple care, I found that I can no longer

start

the

postmaster daemon. When I try, I receive the standard shmget

failed

error message:

FATAL: could not create shared memory segment: Cannot

allocate

memory

DETAIL: Failed system call was shmget(key=5432001,

size=4112384,

03600).

HINT: This error usually means that PostgreSQL's request for

a

shared

memory segment exceeded available memory or swap space. To

reduce

the

request size (currently 4112384 bytes), reduce PostgreSQL's
shared_buffers parameter (currently 300) and/or its

max_connections

parameter (currently 30).

I get this error with either the settings recommended on the

kernel

resources page:

kern.sysv.shmmax=4194304
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024

And I also get it when i set kern.sysv.shmmax=12582912

After making all these changed rebooting doesn't fix anything.

Has anyone ran into this problem, or has any idea as to why

this

would

start to fail so suddenly?

Thanks,
Chris

---------------------------(end of

broadcast)---------------------------

TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

---------------------------(end of

broadcast)---------------------------

TIP 6: explain analyze is your friend

---------------------------(end of

broadcast)---------------------------

TIP 6: explain analyze is your friend

On 5/7/07, Prashant Ranjalkar <prashant.ranjalkar@gmail.com> wrote:

Hi Chris,

Please let me know your shared_buffers & max_connections .
How much RAM your sstem has.
You have set up your shmmax to 12MB.
I hope these DB parameters have larger in values and stopping the allocating
of shared memory segments during start up of the database.
if your system has enough memory then set the shmmax to highier value and
try again.

Hope this will resolve your problem.

Regards,

Prashant Ranjalkar
EnterpriseDB

On 5/7/07, Christopher S Martin <martin.christopher.s@gmail.com> wrote:

No .pid files found in the data directory.
The ipcs output doesn't list anything owned by the postgres user, or by

root.

Thanks,
Chris

On 5/7/07, Prashant Ranjalkar < prashant.ranjalkar@gmail.com> wrote:

Hello,

Please check any .pid file exist in your data directory. If it exists

then

postmaster is running and memory is not freed up.
Also check
ipcs -mp

it will give any shared memory allocated segments if any and consuming

the

memory.

regards
Prashant Ranjalkar

On 5/7/07, Christopher S Martin < martin.christopher.s@gmail.com >

wrote:

sysctl -a reveals the following:
kern.sysv.shmmax: 12582912
kern.sysv.shmmin : 1
kern.sysv.shmmni: 32
kern.sysv.shmseg: 8
kern.sysv.shmall: 1024
kern.sysv.semmni: 87381
kern.sysv.semmns: 87381
kern.sysv.semmnu: 87381
kern.sysv.semmsl : 87381
kern.sysv.semume: 10

I am using the sysctl.conf file in /etc to set these values at boot
time, but in that file I only have the following entries:

kern.sysv.shmmax=12582912
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024

When booting up in unix mode to view the output from all the startup
processes, I do notice that it looks like the sysctl values are read
and set twice, not sure if this would affect anything.

I checked the process listing for any other postmaster processes that
could have been left running, but nothing it showing up. I'm using a
LaunchAgent to start postmaster, so it shouldn't be starting on its
own anyway.

On 5/7/07, Prashant Ranjalkar < prashant.ranjalkar@gmail.com> wrote:

Hello,

The previously running postmaster process might not closed properly

and

released the kernel's memory.
Check for any process running on the server if it exists then kill

the

process.here due to unrelease of kernel's memory and while booting

the

process is not releasing shared memory hence leading to problems.

regards
Prashant Ranjalkar
EnterpriseDB

On 5/7/07, Christopher S Martin < martin.christopher.s@gmail.com>

wrote:

Martin:

They didn't take any memory out of the machine. AS for memory

cache

parameters, I'm don't know about that. How would I go checking

for

that type of thing?

Thanks,
Chris

On 5/6/07, Martin Gainty < mgainty@hotmail.com > wrote:

if you're getting memory errors then a guess would be did they

take

out

any

memory out of your machine or perhaps did they change your

memory

cache

parameters???
Martin
This email message and any files transmitted with it contain

confidential

information intended only for the person(s) to whom this email

message

is

addressed. If you have received this email message in error,

please

notify

the sender immediately by telephone or email and destroy the

original

message without making a copy. Thank you.

----- Original Message -----
From: "Christopher S Martin" < martin.christopher.s@gmail.com >
To: <pgsql-general@postgresql.org>
Sent: Sunday, May 06, 2007 3:07 PM
Subject: [GENERAL] shmget fails on OS X with proper settings

Hi to the list, its my first post.

I was previous running postgres 8.2.1 on my OS X 10.4.9 laptop

with no

problems.
After I sent it to apple care, I found that I can no longer

start

the

postmaster daemon. When I try, I receive the standard shmget

failed

error message:

FATAL: could not create shared memory segment: Cannot

allocate

memory

DETAIL: Failed system call was shmget(key=5432001,

size=4112384,

03600).

HINT: This error usually means that PostgreSQL's request for

a

shared

memory segment exceeded available memory or swap space. To

reduce

the

request size (currently 4112384 bytes), reduce PostgreSQL's
shared_buffers parameter (currently 300) and/or its

max_connections

parameter (currently 30).

I get this error with either the settings recommended on the

kernel

resources page:

kern.sysv.shmmax=4194304
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024

And I also get it when i set kern.sysv.shmmax=12582912

After making all these changed rebooting doesn't fix anything.

Has anyone ran into this problem, or has any idea as to why

this

would

start to fail so suddenly?

Thanks,
Chris

---------------------------(end of

broadcast)---------------------------

TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

---------------------------(end of

broadcast)---------------------------

TIP 6: explain analyze is your friend

---------------------------(end of

broadcast)---------------------------

TIP 6: explain analyze is your friend

On 5/7/07, Christopher S Martin <martin.christopher.s@gmail.com> wrote:

The shared_buffers and max_connections values are both set to the
default values (unchanged i the configuration file). For
max_connections this is 50, and for the shared_buffers I believe the
default is 32mb.

Do you suggest setting the shmmax value to 32mb or greater?

Thanks,
Chris

My development system has 2GB of RAM

On 5/7/07, Prashant Ranjalkar <prashant.ranjalkar@gmail.com> wrote:

Hi Chris,

Please let me know your shared_buffers & max_connections .
How much RAM your sstem has.
You have set up your shmmax to 12MB.
I hope these DB parameters have larger in values and stopping the allocating
of shared memory segments during start up of the database.
if your system has enough memory then set the shmmax to highier value and
try again.

Hope this will resolve your problem.

Regards,

Prashant Ranjalkar
EnterpriseDB

On 5/7/07, Christopher S Martin <martin.christopher.s@gmail.com> wrote:

No .pid files found in the data directory.
The ipcs output doesn't list anything owned by the postgres user, or by

root.

Thanks,
Chris

On 5/7/07, Prashant Ranjalkar < prashant.ranjalkar@gmail.com> wrote:

Hello,

Please check any .pid file exist in your data directory. If it exists

then

postmaster is running and memory is not freed up.
Also check
ipcs -mp

it will give any shared memory allocated segments if any and consuming

the

memory.

regards
Prashant Ranjalkar

On 5/7/07, Christopher S Martin < martin.christopher.s@gmail.com >

wrote:

sysctl -a reveals the following:
kern.sysv.shmmax: 12582912
kern.sysv.shmmin : 1
kern.sysv.shmmni: 32
kern.sysv.shmseg: 8
kern.sysv.shmall: 1024
kern.sysv.semmni: 87381
kern.sysv.semmns: 87381
kern.sysv.semmnu: 87381
kern.sysv.semmsl : 87381
kern.sysv.semume: 10

I am using the sysctl.conf file in /etc to set these values at boot
time, but in that file I only have the following entries:

kern.sysv.shmmax=12582912
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024

When booting up in unix mode to view the output from all the startup
processes, I do notice that it looks like the sysctl values are read
and set twice, not sure if this would affect anything.

I checked the process listing for any other postmaster processes that
could have been left running, but nothing it showing up. I'm using a
LaunchAgent to start postmaster, so it shouldn't be starting on its
own anyway.

On 5/7/07, Prashant Ranjalkar < prashant.ranjalkar@gmail.com> wrote:

Hello,

The previously running postmaster process might not closed properly

and

released the kernel's memory.
Check for any process running on the server if it exists then kill

the

process.here due to unrelease of kernel's memory and while booting

the

process is not releasing shared memory hence leading to problems.

regards
Prashant Ranjalkar
EnterpriseDB

On 5/7/07, Christopher S Martin < martin.christopher.s@gmail.com>

wrote:

Martin:

They didn't take any memory out of the machine. AS for memory

cache

parameters, I'm don't know about that. How would I go checking

for

that type of thing?

Thanks,
Chris

On 5/6/07, Martin Gainty < mgainty@hotmail.com > wrote:

if you're getting memory errors then a guess would be did they

take

out

any

memory out of your machine or perhaps did they change your

memory

cache

parameters???
Martin
This email message and any files transmitted with it contain

confidential

information intended only for the person(s) to whom this email

message

is

addressed. If you have received this email message in error,

please

notify

the sender immediately by telephone or email and destroy the

original

message without making a copy. Thank you.

----- Original Message -----
From: "Christopher S Martin" < martin.christopher.s@gmail.com >
To: <pgsql-general@postgresql.org>
Sent: Sunday, May 06, 2007 3:07 PM
Subject: [GENERAL] shmget fails on OS X with proper settings

Hi to the list, its my first post.

I was previous running postgres 8.2.1 on my OS X 10.4.9 laptop

with no

problems.
After I sent it to apple care, I found that I can no longer

start

the

postmaster daemon. When I try, I receive the standard shmget

failed

error message:

FATAL: could not create shared memory segment: Cannot

allocate

memory

DETAIL: Failed system call was shmget(key=5432001,

size=4112384,

03600).

HINT: This error usually means that PostgreSQL's request for

a

shared

memory segment exceeded available memory or swap space. To

reduce

the

request size (currently 4112384 bytes), reduce PostgreSQL's
shared_buffers parameter (currently 300) and/or its

max_connections

parameter (currently 30).

I get this error with either the settings recommended on the

kernel

resources page:

kern.sysv.shmmax=4194304
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024

And I also get it when i set kern.sysv.shmmax=12582912

After making all these changed rebooting doesn't fix anything.

Has anyone ran into this problem, or has any idea as to why

this

would

start to fail so suddenly?

Thanks,
Chris

---------------------------(end of

broadcast)---------------------------

TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

---------------------------(end of

broadcast)---------------------------

TIP 6: explain analyze is your friend

---------------------------(end of

broadcast)---------------------------

TIP 6: explain analyze is your friend

On 5/7/07, Isak Hansen <isak.hansen@gmail.com> wrote:

On 5/7/07, Christopher S Martin <martin.christopher.s@gmail.com> wrote:

sysctl -a reveals the following:
kern.sysv.shmmax: 12582912

Maximum size of shared memory segment (afaik bytes - needs to be a
multiple of 4096).

kern.sysv.shmall: 1024

Total amount of shared memory available (afaik pages of 4k).

Shouldn't matter how large you make shmmax if there's not enough
shared memory to allocate chunks from.

My settings:
kern.sysv.shmmax: 134217728
kern.sysv.shmmin: 1
kern.sysv.shmmni: 32
kern.sysv.shmseg: 8
kern.sysv.shmall: 32768

and shared_buffers = 80MB. Probably a bit excessive for my dev box, but..

HTH,
Isak

On 5/7/07, Jim Nasby <decibel@decibel.org> wrote:

On May 7, 2007, at 9:11 AM, Tom Lane wrote:

I believe BTW that you
need to do "sudo ipcs -a" to be sure of seeing everything; otherwise
OS X's ipcs silently doesn't tell you about segments your userid
doesn't
have access to.

Actually, it seems that you don't get anything back when ipcs is run
as non-root...

decibel@platter.1[10:41]~/pgsql/HEAD:58%ipcs -a|grep decibel
decibel@platter.1[10:41]~/pgsql/HEAD:59%sudo ipcs -a|grep decibel
m 3080191 5555001 --rw------- decibel decibel decibel
decibel 3 38133760 11042 11042 9:00:53 10:41:53 9:00:53
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)