Re: fix bgworkers in EXEC_BACKEND

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

In response to

Responses

Browse pgsql-hackers by date

  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