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. For rest of the world, it's just a
string guc and is written to and read from any external file as one (e.g.
the file that write_nondefault_variables() writes to in the EXEC_BACKEND
case). I hope I'm not entirely missing the point of the discussion you
and Amit are having.
Thanks,
Amit