|
|
 | | From: | elein | | Subject: | shared_buffers vs. -B flag: 7.4 | | Date: | Sun, 23 Jan 2005 10:38:27 -0800 |
|
|
 | 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
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
|
|
| | From: | Tom Lane | | Subject: | Re: shared_buffers vs. -B flag: 7.4 | | Date: | Sun, 23 Jan 2005 14:15:07 -0500 |
|
|
| 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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
|
|
| | From: | elein | | Subject: | Re: shared_buffers vs. -B flag: 7.4 | | Date: | Sun, 23 Jan 2005 12:28:08 -0800 |
|
|
| 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 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
|
|
| | From: | Tom Lane | | Subject: | Re: shared_buffers vs. -B flag: 7.4 | | Date: | Sun, 23 Jan 2005 15:46:36 -0500 |
|
|
| 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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
|
|
|
