On Thu, Apr 7, 2016 at 7:29 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> 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.
So, will you write the patch? Either current implementation or
the approach you're suggesting works to me. If you really want
to change the current one, I'm happy to review that.
Regards,
--
Fujii Masao
