Re: shared_buffers vs. -B flag: 7.4 - Mailing list pgsql-bugs

From elein@varlena.com (elein)
Subject Re: shared_buffers vs. -B flag: 7.4
Date
Msg-id 20050123202808.GT15269@varlena.com
Whole thread Raw
In response to Re: shared_buffers vs. -B flag: 7.4  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: shared_buffers vs. -B flag: 7.4
List pgsql-bugs
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
>

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: shared_buffers vs. -B flag: 7.4
Next
From: Tom Lane
Date:
Subject: Re: shared_buffers vs. -B flag: 7.4