Skip site navigation (1) Skip section navigation (2)

shared_buffers vs. -B flag: 7.4

From: elein(at)varlena(dot)com (elein)
To: pgsql-bugs(at)postgresql(dot)org
Cc: elein <elein(at)varlena(dot)com>
Subject: shared_buffers vs. -B flag: 7.4
Date: 2005-01-23 18:38:27
Message-ID: 20050123183827.GP15269@varlena.com (view raw or flat)
Thread:
Lists: pgsql-bugs
This was reproduced on 7.4. I don't know
if it is still an issue on 8.0.

If you set shared_buffers (shmem_max)
to greater than the shmem config on the
OS pg will not start.  And gives a useful
message (below).

However, if you use the -B option on the pg_ctl
start up, postgres starts up fine.  And
the shared_buffers value shown by show
is the higher value.

These options should work the same.

--elein
elein(at)varlena(dot)com


waiting for postmaster to start...2005-01-04 01:20:09 [45468] 
FATAL:could not create shared memory segment: Invalid argument

DETAIL:  Failed system call was shmget(key=2010001, size=555876352, 03600).
HINT:  This error usually means that PostgreSQL's request for a shared memory
segment exceeded your kernel's SHMMAX parameter.  You can either reduce the
request size or reconfigure the kernel with larger SHMMAX.  To reduce the
request size (currently 555876352 bytes), reduce PostgreSQL's shared_buffers
parameter (currently 65535) and/or its max_connections parameter (currently 138).

If the request size is already small, it's possible that it is
less than your kernel's SHMMIN parameter, in which case raising the
request size or reconfiguring SHMMIN is called for.

The PostgreSQL documentation contains more information
about shared memory configuration.

.............................................................failed 
pg_ctl: postmaster does not start


Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2005-01-23 19:15:07
Subject: Re: shared_buffers vs. -B flag: 7.4
Previous:From: Florin BorsaDate: 2005-01-23 17:39:05
Subject: BUG #1436: not null condition is not respected

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group