BUG #7713: Is it a good idea to write more?

Поиск
Список
Период
Сортировка
От jackie.qq.zhang@gmail.com
Тема BUG #7713: Is it a good idea to write more?
Дата
Msg-id E1Te01O-0006IX-16@wrigleys.postgresql.org
обсуждение исходный текст
Ответы Re: BUG #7713: Is it a good idea to write more?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
The following bug has been logged on the website:

Bug reference:      7713
Logged by:          Jackie Zhang
Email address:      jackie.qq.zhang@gmail.com
PostgreSQL version: 9.2.1
Operating system:   Ubuntu
Description:        =


Hi, =


This actually not a bug but an enhanced log message. =


I encountered an issue that my PostgreSQL server refused to start with the
following messages:

-----------------------------------

FATAL:  could not create shared memory segment: Invalid argument
DETAIL:  Failed system call was shmget(key=3D5432001, size=3D207691268096,
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 207691268096 bytes), reduce PostgreSQL's
shared memory usage, perhaps by reducing shared_buffers or max_connections.
   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.

-----------------------------------

Then, I checked and tuned very very hard the two configuration parameters
mentioned in the log, i.e.,
 =

shared_buffers
max_connections

but failed to make it work =E2=80=93 the problem actually is not caused by =
these
two. I asked some PG guru to =

check my configuration file, and it finally turned out to be the
inappropriate =E2=80=9Cautovacuum_max_workers" settings.

After reading the manual =E2=80=9CManaging Kernel Resources=E2=80=9D, I fin=
d the shared
memory is calculated using the following configuration parameters (Table
17-2):

Usage                                Approximate shared memory bytes
required (as of 8.3) =

Connections                      (1800 + 270 * max_locks_per_transaction) *
max_connections =

Autovacuum workers        (1800 + 270 * max_locks_per_transaction) *
autovacuum_max_workers Prepared transactions        (770 + 270 *
max_locks_per_transaction) * max_prepared_transactions =

Shared disk buffers           (block_size + 208) * shared_buffers =

WAL buffers                     (wal_block_size + 8) * wal_buffers =

Fixed space requirements 770 kB

So, I wonder can we simply write this in the log message to make it more
clear? I definitely think it's easy for we users to understand and quickly
figure out the problem. Currently, the log only mentioned two configuration
parameters which may mislead users who is dumb as I. =


Here is the patch I made. I think it's even better to write down the
equation (Table 17-2) but I don't know whether the numbers (i.e., 1800, 270)
are only used for example.

-----------------------------------

-- src/backend/port/sysv_shmem.c       2012-09-19 14:47:58.000000000 -0700
+++ ../../postgresql-9.2.1/src/backend/port/sysv_shmem.c        2012-11-29
00:59:32.656158310 -0800
@@ -150,12 +150,18 @@
                  "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 %lu
bytes), reduce "
-                                                "PostgreSQL's shared memory
usage, perhaps by reducing shared_buffers "
-                                                "or max_connections.\n"
-                                                "If the request size is
already small, it's possible that it is less than "
+                                                "PostgreSQL's shared memory
usage, perhaps by reducing the following configuration parameters:\n"
+               "  shared_buffers\n"
+                               "  wal_buffers\n"
+                               "  max_connections\n"
+                               "  autovacuum_max_workers\n"
+                               "  max_prepared_transactions\n"
+                               "  max_locks_per_transaction\n"
+                               "  max_pred_locks_per_transaction\n"
+                               "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.\n"
-               "The PostgreSQL documentation contains more information
about shared "
+               "The PostgreSQL documentation (\"Managing Kernel
Resources\") contains more information about shared "
                                                 "memory configuration.",
                                                 (unsigned long) size) : 0,
                                 (errno =3D=3D ENOMEM) ?

-----------------------------------

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: BUG #7711: Accessing nested composite types in PL/PgSQL doesn't work
Следующее
От: francois.bonzon@gmail.com
Дата:
Сообщение: BUG #7712: pgsql2shp should set Language Driver ID (LDID) header in .dbf