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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
