Stephen Frost wrote: > * Heikki Linnakangas (hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
