Heikki Linnakangas wrote:
> On 27.12.2012 22:46, Alvaro Herrera wrote:
> >Heikki Linnakangas wrote:
> >
> >>Might be cleaner to directly assign the correct value to MaxBackends
> >>above, ie. "MaxBackends = MaxConnections + newval + 1 +
> >>GetNumShmemAttachedBgworkers()". With a comment to remind that it
> >>needs to be kept in sync with the other places where that
> >>calculation is done, in guc.c. Or put that calculation in a new
> >>function and call it above and in guc.c.
> >>
> >>Thinking about this some more, it might be cleaner to move the
> >>responsibility of setting MaxBackends out of guc.c, into
> >>postmaster.c. The guc machinery would set max_connections and
> >>autovacuum_max_workers as usual, but not try to set MaxBackends.
> >>After reading the config file in postmaster.c, calculate
> >>MaxBackends.
Actually this patch still needed one more change, because we weren't
rechecking that we're not beyond the MAX_BACKENDS value after bgworker
registration.
This is hard to hit, because with the current compile constants you need
over eight million backends in total to hit that limit (and 360 GB of
shared memory), but it seems dangerous to leave that without any
protection.
I kinda hate this a bit because I had to move MAX_BACKENDS from a
private value in guc.c to postmaster.h. But the wording of the error
message is what took the most time:
+ ereport(LOG,
+ (errcode(ERRCODE_CONFIGURATION_LIMIT_EXCEEDED),
+ errmsg("too many background workers"),
+ errdetail("Up to %d background workers can be registered with the current settings.",
+ MAX_BACKENDS - (MaxConnections + autovacuum_max_workers + 1))));
Completely different ideas for this error message are welcome. My first
try enumerated all the variables involved.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services