From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: fix bgworkers in EXEC_BACKEND |
Date: | 2012-12-27 18:16:21 |
Message-ID: | 20121227181621.GA16126@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Heikki Linnakangas (hlinnakangas(at)vmware(dot)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). I realize
that's pretty pie-in-the-sky, but it sure would be nice to reduce the
number of parameters that require a full restart.
All that said, putting those functions back and changing guc.c would
certainly be pretty trivially done, should some new patch come along
that would allow online changing of max_connections.
So, +1 on Heikki's approach.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2012-12-27 18:17:58 | Re: fix bgworkers in EXEC_BACKEND |
Previous Message | Heikki Linnakangas | 2012-12-27 18:06:07 | Re: fix bgworkers in EXEC_BACKEND |