Re: shmget error text reports funny max_connections numbers

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: shmget error text reports funny max_connections numbers
Date: 2011-02-27 17:22:49
Message-ID: 201102271722.p1RHMnJ04259@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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(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
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Attachment Content-Type Size
/rtmp/shmem.diff text/x-diff 2.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-02-27 17:24:43 Re: WIP: cross column correlation ...
Previous Message Marko Tiikkaja 2011-02-27 17:14:41 Re: wCTE: about the name of the feature