Re: Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 8:11 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Wed, Apr 6, 2016 at 11:14 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
> > On Wed, Apr 6, 2016 at 7:03 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
wrote:
> >>
> >> On Wed, Apr 6, 2016 at 8:59 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> >> wrote:
> >> >
> >> >> BTW, we can move SyncRepUpdateConfig() just after
ProcessConfigFile()
> >> >> from pg_stat_get_wal_senders() and every backends always parse the
> >> >> value
> >> >> of s_s_names when the setting is changed.
> >> >>
> >> >
> >> > That sounds appropriate, but not sure what is exact place to call it.
> >>
> >> Maybe just after the following ProcessConfigFile().
> >>
> >> -----------------------------------------
> >> /*
> >> * (6) check for any other interesting events that happened while we
> >> * slept.
> >> */
> >> if (got_SIGHUP)
> >> {
> >> got_SIGHUP = false;
> >> ProcessConfigFile(PGC_SIGHUP);
> >> }
> >> -----------------------------------------
> >>
> >> If we do the move, we also need to either (1) make postmaster call
> >> SyncRepUpdateConfig() and pass the parsed result to any forked backends
> >> via a file like write_nondefault_variables() does for EXEC_BACKEND
> >> environment, or (2) make a backend call SyncRepUpdateConfig() during
> >> its initialization phase so that the first call of pg_stat_replication
> >> can use the parsed result. (1) seems complicated and overkill.
> >> (2) may add very small overhead into the fork of a backend. It would
> >> be almost negligible, though. So which logic should we adopt?
> >>
> >
> > Won't it be possible to have assign_* function for
synchronous_standby_names
> > as we have for some of the other settings like assign_XactIsoLevel and
then
> > call SyncRepUpdateConfig() in that function?
>
> It's possible, but still seems to need (1), i.e., the variable that
assign_XXX
> function assigned needs to be passed to a backend via file for
EXEC_BACKEND
> environment.
>

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.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com