Re: Support for N synchronous standby servers - take 2 - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Support for N synchronous standby servers - take 2
Date
Msg-id CAHGQGwG4Mw70LM+Nx-9=1+-udU6BOQ9kqCkXZwPxA9FV4H1jaw@mail.gmail.com
Whole thread Raw
In response to Re: Support for N synchronous standby servers - take 2  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Support for N synchronous standby servers - take 2  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Support for N synchronous standby servers - take 2  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-hackers
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:
>>
>> On Thu, Apr 7, 2016 at 1:22 PM, Amit Kapila <amit.kapila16@gmail.com>
>> wrote:
>> >
>> > But for that, I think we don't need to do anything extra.  I mean
>> > write_nondefault_variables() will automatically write the non-default
>> > value
>> > of variable and then during backend initialization, it will call
>> > read_nondefault_variables which will call set_config_option for
>> > non-default
>> > parameters and that should set the required value if we have assign_*
>> > function defined for the variable.
>>
>> 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.

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: "Karl O. Pinc"
Date:
Subject: Re: Patch to implement pg_current_logfile() function
Next
From: Michael Paquier
Date:
Subject: Re: Speedup twophase transactions