On Thu, Apr 7, 2016 at 1:30 PM, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote: > > On 2016/04/07 15:26, Fujii Masao wrote: > > On Thu, Apr 7, 2016 at 2:48 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > >> On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao <masao.fujii@gmail.com> wrote: > >>> 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. > > I don't see why there is need to SyncRepUpdateConfig() after every fork or > anywhere outside syncrep.c/walsender.c for that matter. AIUI, only > walsender or a backend that runs pg_stat_get_wal_senders() ever needs to > run SyncRepUpdateConfig() to get parsed synchronous standbys info from the > string that is SyncRepStandbyNames.
>
So if we go by this each time backend calls pg_stat_get_wal_senders, it needs to do parsing to form SyncRepConfig whether it's changed or not from previous time. I understand that this is not a performance critical path, but still if we can do it in some other optimal way which doesn't hurt any other path, then it will be better.
