Обсуждение: shmget error text reports funny max_connections numbers

Поиск
Список
Период
Сортировка

shmget error text reports funny max_connections numbers

От
Peter Eisentraut
Дата:
Since MaxBackends is actually max_connections + autovacuum_max_workers +
1, when you get an error message from shmget() it will tell you

"reduce ... its max_connections parameter (currently 104)"

when you actually set

max_connections = 100

This looks a bit silly.

Should we just make the error messages report MaxBackends -
autovacuum_max_workers - 1, or is it worthwhile calling out
autovacuum_max_workers separately?




Re: shmget error text reports funny max_connections numbers

От
Robert Haas
Дата:
On Wed, Oct 13, 2010 at 2:39 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> Since MaxBackends is actually max_connections + autovacuum_max_workers +
> 1, when you get an error message from shmget() it will tell you
>
> "reduce ... its max_connections parameter (currently 104)"
>
> when you actually set
>
> max_connections = 100
>
> This looks a bit silly.
>
> Should we just make the error messages report MaxBackends -
> autovacuum_max_workers - 1, or is it worthwhile calling out
> autovacuum_max_workers separately?

I suppose there are other reasons we could run out of shared memory,
too.  max_locks_per_transaction, for example.  It might be good to
revise the wording of the message so as to suggest that these are only
some of the possible causes.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Re: shmget error text reports funny max_connections numbers

От
Alvaro Herrera
Дата:
Excerpts from Robert Haas's message of jue oct 14 21:36:48 -0300 2010:
> On Wed, Oct 13, 2010 at 2:39 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> > Since MaxBackends is actually max_connections + autovacuum_max_workers +
> > 1, when you get an error message from shmget() it will tell you
> >
> > "reduce ... its max_connections parameter (currently 104)"
> >
> > when you actually set
> >
> > max_connections = 100
> >
> > This looks a bit silly.
> >
> > Should we just make the error messages report MaxBackends -
> > autovacuum_max_workers - 1, or is it worthwhile calling out
> > autovacuum_max_workers separately?
> 
> I suppose there are other reasons we could run out of shared memory,
> too.  max_locks_per_transaction, for example.  It might be good to
> revise the wording of the message so as to suggest that these are only
> some of the possible causes.

Agreed.  Something like "reduce one or more of the following parameters:
shared_buffers (currently NN), max_connections (currently NN),
autovacuum_max_workers (currently MM), 

I also suggest that it would be good to revise these things so that
sentences within those monstruous paragraphs can be translated
separately.  Maybe changing the ErrorData stuff so that there can be
more than one errhint field?  If that's too much trouble, perhaps having
"%s. %s. %s. %s" as the first errhint parameter, and have each sentence
be its own translatable unit.

I also just noticed that we use stars for emphasis here, "This error
does *not* mean..." which is maybe too cute.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


Re: shmget error text reports funny max_connections numbers

От
Bruce Momjian
Дата:
I have applied a patch to improve shared memory failure reporting,
attached.  We no longer report actual parameter _values_ and suggest
that other parameters might also cause such failures.

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

Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of jue oct 14 21:36:48 -0300 2010:
> > On Wed, Oct 13, 2010 at 2:39 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> > > Since MaxBackends is actually max_connections + autovacuum_max_workers +
> > > 1, when you get an error message from shmget() it will tell you
> > >
> > > "reduce ... its max_connections parameter (currently 104)"
> > >
> > > when you actually set
> > >
> > > max_connections = 100
> > >
> > > This looks a bit silly.
> > >
> > > Should we just make the error messages report MaxBackends -
> > > autovacuum_max_workers - 1, or is it worthwhile calling out
> > > autovacuum_max_workers separately?
> >
> > I suppose there are other reasons we could run out of shared memory,
> > too.  max_locks_per_transaction, for example.  It might be good to
> > revise the wording of the message so as to suggest that these are only
> > some of the possible causes.
>
> Agreed.  Something like "reduce one or more of the following parameters:
> shared_buffers (currently NN), max_connections (currently NN),
> autovacuum_max_workers (currently MM),
>
> I also suggest that it would be good to revise these things so that
> sentences within those monstruous paragraphs can be translated
> separately.  Maybe changing the ErrorData stuff so that there can be
> more than one errhint field?  If that's too much trouble, perhaps having
> "%s. %s. %s. %s" as the first errhint parameter, and have each sentence
> be its own translatable unit.
>
> I also just noticed that we use stars for emphasis here, "This error
> does *not* mean..." which is maybe too cute.
>
> --
> Álvaro Herrera <alvherre@commandprompt.com>
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/src/backend/port/sysv_shmem.c b/src/backend/port/sysv_shmem.c
index aece026..aba6fa8 100644
--- a/src/backend/port/sysv_shmem.c
+++ b/src/backend/port/sysv_shmem.c
@@ -153,25 +153,25 @@ InternalIpcMemoryCreate(IpcMemoryKey memKey, Size size)
           "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_buffers parameter (currently %d) and/or "
-                         "its max_connections parameter (currently %d).\n"
+                       "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 "
                          "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 "
                          "memory configuration.",
-                         (unsigned long) size, NBuffers, MaxBackends) : 0,
+                         (unsigned long) size) : 0,
                  (errno == ENOMEM) ?
                  errhint("This error usually means that PostgreSQL's request for a shared "
                    "memory segment exceeded available memory or swap space, "
                          "or exceeded your kernel's SHMALL parameter.  You can either "
                          "reduce the request size or reconfigure the kernel with larger SHMALL.  "
                   "To reduce the request size (currently %lu bytes), reduce "
-               "PostgreSQL's shared_buffers parameter (currently %d) and/or "
-                         "its max_connections parameter (currently %d).\n"
+                       "PostgreSQL's shared memory usage, perhaps by reducing shared_buffers"
+                         "or max_connections.\n"
         "The PostgreSQL documentation contains more information about shared "
                          "memory configuration.",
-                         (unsigned long) size, NBuffers, MaxBackends) : 0,
+                         (unsigned long) size) : 0,
                  (errno == ENOSPC) ?
                  errhint("This error does *not* mean that you have run out of disk space. "
                          "It occurs either if all available shared memory IDs have been taken, "
@@ -179,11 +179,10 @@ InternalIpcMemoryCreate(IpcMemoryKey memKey, Size size)
           "or because the system's overall limit for shared memory has been "
                  "reached.  If you cannot increase the shared memory limit, "
           "reduce PostgreSQL's shared memory request (currently %lu bytes), "
-            "by reducing its shared_buffers parameter (currently %d) and/or "
-                         "its max_connections parameter (currently %d).\n"
+                   "perhaps by reducing shared_buffers or max_connections.\n"
         "The PostgreSQL documentation contains more information about shared "
                          "memory configuration.",
-                         (unsigned long) size, NBuffers, MaxBackends) : 0));
+                         (unsigned long) size) : 0));
     }

     /* Register on-exit routine to delete the new segment */