Re: shmget error text reports funny max_connections numbers

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(at)gmx(dot)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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support