Alvaro Herrera wrote:
> One notable thing is that I had to introduce this in the postmaster
> startup sequence:
>
> /*
> * process any libraries that should be preloaded at postmaster start
> */
> process_shared_preload_libraries();
>
> /*
> * If loadable modules have added background workers, MaxBackends needs to
> * be updated. Do so now.
> */
> // RerunAssignHook("max_connections");
> if (GetNumShmemAttachedBgworkers() > 0)
> SetConfigOption("max_connections",
> GetConfigOption("max_connections", false, false),
> PGC_POSTMASTER, PGC_S_OVERRIDE);
>
> Note the intention here is to re-run the GUC assign hook for
> max_connections (hence the commented out hypothetical call to do so).
> Obviously, having to go through GetConfigOption and SetConfigOption is
> not a nice thing to do; we'll have to add some new entry point to guc.c
> for this to have a nicer interface.
After fooling with guc.c to create such a new entry point, I decided
that it looks too ugly. guc.c is already complex enough with the API we
have today that I don't want to be seen creating a partially-duplicate
interface, even if it is going to result in simplified processing of
this one place. If we ever get around to needing another place to
require rerunning a variable's assign_hook we can discuss it; for now it
doesn't seem worth it.
This is only called at postmaster start time, so it's not too
performance-sensitive, hence SetConfigOption( .., GetConfigOption(), ..)
seems acceptable from that POV.
--
Á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
