At Wed, 13 Apr 2016 04:43:35 +0900, Fujii Masao <masao.fu...@gmail.com> wrote in <cahgqgwemzhbdjb1x3+ktuu9vv5xnhgcbo4tejiboxf_vhae...@mail.gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
