Horton

Thread

  1. shmget error text reports funny max_connections numbers

    Peter Eisentraut <peter_e@gmx.net> — 2010-10-13T18:39:36Z

    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?

  2. Re: shmget error text reports funny max_connections numbers

    Robert Haas <robertmhaas@gmail.com> — 2010-10-15T00:36:48Z

    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

  3. Re: shmget error text reports funny max_connections numbers

    Alvaro Herrera <alvherre@commandprompt.com> — 2010-10-15T01:16:22Z

    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

  4. Re: shmget error text reports funny max_connections numbers

    Bruce Momjian <bruce@momjian.us> — 2011-02-27T17:22:49Z

    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. +