Thread: shared_buffers vs. -B flag: 7.4

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@varlena.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

elein@varlena.com (elein) writes:
> 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.

It behaves as expected for me, in both 7.4 and CVS tip.  Are you sure
your test case wasn't such that the higher -B value in fact worked?
(For instance, maybe you stopped another postmaster that was using some
of the shmem.)

$ postmaster -B 65000
FATAL:  could not create shared memory segment: Not enough space
DETAIL:  Failed system call was shmget(key=5474001, size=543997952, 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 543997952 bytes), reduce PostgreSQL's shared_buffers parameter (currently
65000)and/or its max_connections parameter (currently 100). 
        The PostgreSQL documentation contains more information about shared memory configuration.
$

            regards, tom lane

Hmmm. This was reproduced at a customer site by
a very meticulous dba.  I'll check back with him.
But I'm glad to know it is not an on-going problem.

thanks for your quick response

--elein

On Sun, Jan 23, 2005 at 02:15:07PM -0500, Tom Lane wrote:
> elein@varlena.com (elein) writes:
> > 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.
>
> It behaves as expected for me, in both 7.4 and CVS tip.  Are you sure
> your test case wasn't such that the higher -B value in fact worked?
> (For instance, maybe you stopped another postmaster that was using some
> of the shmem.)
>
> $ postmaster -B 65000
> FATAL:  could not create shared memory segment: Not enough space
> DETAIL:  Failed system call was shmget(key=5474001, size=543997952, 03600).
> HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or
swapspace. To reduce the request size (currently 543997952 bytes), reduce PostgreSQL's shared_buffers parameter
(currently65000) and/or its max_connections parameter (currently 100). 
>         The PostgreSQL documentation contains more information about shared memory configuration.
> $
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>                http://archives.postgresql.org
>

elein@varlena.com (elein) writes:
> Hmmm. This was reproduced at a customer site by
> a very meticulous dba.  I'll check back with him.

It would be worth enquiring exactly what values he was testing.
IIRC, 7.4 doesn't have any defense against setting NBuffers so large
as to make the shmem segment size calculation overflow.
This would of course lead to crashes at runtime, but I think the
postmaster startup would complete ...

            regards, tom lane