On Thu, Apr 7, 2016 at 1:30 PM, Amit Langote <langote_amit...@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.kapil...@gmail.com> wrote: > >> On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao <masao.fu...@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. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
