Re: fix bgworkers in EXEC_BACKEND - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: fix bgworkers in EXEC_BACKEND
Date
Msg-id 20121227184913.GC4238@alvh.no-ip.org
Whole thread Raw
In response to Re: fix bgworkers in EXEC_BACKEND  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost wrote:
> * Heikki Linnakangas (hlinnakangas@vmware.com) wrote:
> > 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.
>
> I tend to prefer Heikki's solution wrt supporting what we do currently.
> I do wonder if, perhaps, the reason the assign_XXX() functions were put
> in place and used from GUC was a hope that some day we'd actually
> support online changing of max_connections (and friends).

No, that's not the reason.  The reason is that the "check" hooks did not
exist at all, so both the check and the assignment were done in the
assign hook.  Now we're getting rid of the assignment hooks because
they're useless, but the check hooks must, of course, remain.  We put
the hooks in because it was the simplest thing we could think of to set
MaxBackends when either max_connections or autovacuum_max_workers were
tweaked.  My guess is if we had thought of propagating MaxBackends via
BackendParameters back then, we'd probably gone that route as well.
But certainly we had no intention to make max_connections online changeable.

I too like Heikki's proposed patch much better than mine.  Thanks.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: fix bgworkers in EXEC_BACKEND
Next
From: Tom Lane
Date:
Subject: Re: fix bgworkers in EXEC_BACKEND