On Thu, Apr 7, 2016 at 2:48 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao <masao.fu...@gmail.com> wrote: >> >> On Thu, Apr 7, 2016 at 1:22 PM, Amit Kapila <amit.kapil...@gmail.com> >> wrote: >> > >> > But for that, I think we don't need to do anything extra. I mean >> > write_nondefault_variables() will automatically write the non-default >> > value >> > of variable and then during backend initialization, it will call >> > read_nondefault_variables which will call set_config_option for >> > non-default >> > parameters and that should set the required value if we have assign_* >> > function defined for the variable. >> >> Yes if the variable that we'd like to pass to a backend is BOOL, INT, >> REAL, STRING or ENUM. But SyncRepConfig variable is a bit more >> complicated. >> > > SyncRepConfig is a parsed result of SyncRepStandbyNames, why you want to > pass that? I assume that current non-default value of SyncRepStandbyNames > will be passed via write_nondefault_variables(), so we can use that to > regenerate SyncRepConfig.
Yes, so SyncRepUpdateConfig() needs to be called by a backend after fork, to regenerate SyncRepConfig from the passed value of SyncRepStandbyNames. This is the approach of (2) which I explained upthread. assign_XXX function doesn't seem to be helpful for this case. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
