Re: Support for N synchronous standby servers - take 2

At Wed, 13 Apr 2016 04:43:35 +0900, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote in <CAHGQGwEmZhBdjb1x3+KtUU9VV5xnhgCBO4TejibOXF_VHaeVXg(at)mail(dot)gmail(dot)com>
> >>> Thank you for reviewing.
> >>>
> >>> SyncRepUpdateConfig() seems to be no longer necessary.
> >>
> >> Really? I was thinking that something like that function needs to
> >> be called at the beginning of a backend and walsender in
> >> EXEC_BACKEND case. No?
> >>
> >
> > Hmm, in EXEC_BACKEND case, I guess that each child process calls
> > read_nondefault_variables that parses and validates these
> > configuration parameters in SubPostmasterMain.
>
> SyncRepStandbyNames is passed but SyncRepConfig is not, I think.

SyncRepStandbyNames is passed to exec'ed backends by
read_nondefault_variables, which calls set_config_option, which
calls check/assign_s_s_names then syncrep_yyparse, which sets
SyncRepConfig.

Since guess battle is a waste of time, I actually built and ran
on Windows7 and observed that SyncRepConfig has been set before
WalSndLoop starts.

> LOG: check_s_s_names(pid=20596, newval=)
> LOG: assign_s_s_names(pid=20596, newval=, SyncRepConfig=00000000)
> LOG: read_nondefault_variables(pid=20596)
> LOG: set_config_option(synchronous_standby_names)(pid=20596)
> LOG: check_s_s_names(pid=20596, newval=2[standby,sby2,sby3])
> LOG: assign_s_s_names(pid=20596, newval=2[standby,sby2,sby3], SyncRepConfig=01383598)
> LOG: WalSndLoop(pid=20596)

By the way, the patch assumes that one check_s_s_names is
followed by exactly one assign_s_s_names. I suppose that myextra
should be handled without such assumption.

Plus, the name myextra should be any saner name..

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center