On Mon, Apr 24, 2017 at 2:55 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> On Thu, Apr 20, 2017 at 9:31 AM, Kyotaro HORIGUCHI
> <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
>> Ok, I got the point.
>>
>> At Wed, 19 Apr 2017 17:39:01 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote
in<20170419.173901.16598616.horiguchi.kyotaro@lab.ntt.co.jp>
>>> > >> | <para>
>>> > >> | Quorum-based synchronous replication is basically more
>>> > >> | efficient than priority-based one when you specify multiple
>>> > >> | standbys in <varname>synchronous_standby_names</> and want
>>> > >> | to synchronously replicate transactions to two or more of
>>> > >> | them.
>>
>> "Some" means "not all".
>>
>>> > >> | In the priority-based case, the replication master
>>> > >> | must wait for a reply from the slowest standby in the
>>> > >> | required number of standbys in priority order, which may
>>> > >> | slower than the rest.
>>
>>
>> Quorum-based synchronous replication is expected to be more
>> efficient than priority-based one when your master doesn't need
>> to be in sync with all of the nominated standbys by
>> <varname>synchronous_standby_names</>.
This description may be invalid in the case where the requested number
of sync standbys is smaller than the number of "nominated" standbys by
s_s_names. For example, please imagine the case where there are five
standbys nominated by s_s_name, the requested number of sync standbys
is 2, and only two sync standbys are running. In this case, the master
needs to wait for those two standbys whatever the sync rep method is.
I think that we should rewrite that to something like "quorum-based
synchronous replication is more effecient when the requested number
of synchronous standbys is smaller than the number of potential
synchronous standbys running".
> While quorum-based
>> replication master waits only for a specified number of fastest
>> standbys, priority-based replicatoin master must wait for
>> standbys at the top of the list, which may be slower than the
>> rest.
>
> This description looks good to me. I've updated the patch based on
> this description and attached it.
But I still think that the original description that I used in my patch is
better than this....
Regards,
--
Fujii Masao
