On Thu, Apr 7, 2016 at 11:56 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > > 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. >
Then where do you want to call it? Also, this is only required for EXEC_BACKEND builds. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
