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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to