On Mon, Dec 19, 2016 at 9:49 PM, Fujii Masao <masao.fu...@gmail.com> wrote:
> On Sun, Dec 18, 2016 at 9:36 PM, Michael Paquier
> <michael.paqu...@gmail.com> wrote:
>> On Fri, Dec 16, 2016 at 10:42 PM, Fujii Masao <masao.fu...@gmail.com> wrote:
>>> Attached is the modified version of the patch. Barring objections, I will
>>> commit this version.
>> There is a whitespace:
>> $ git diff master --check
>> src/backend/replication/syncrep.c:39: trailing whitespace.
>> + *
> Okey, pushed the patch with this fix. Thanks!

Thank you for reviewing and commit!

> Regarding this feature, there are some loose ends. We should work on
> and complete them until the release.
> (1)
> Which synchronous replication method, priority or quorum, should be
> chosen when neither FIRST nor ANY is specified in s_s_names? Right now,
> a priority-based sync replication is chosen for keeping backward
> compatibility. However some hackers argued to change this decision
> so that a quorum commit is chosen because they think that most users
> prefer to a quorum.
> (2)
> There will be still many source comments and documentations that
> we need to update, for example, in high-availability.sgml. We need to
> check and update them throughly.

Will try to update them.

> (3)
> The priority value is assigned to each standby listed in s_s_names
> even in quorum commit though those priority values are not used at all.
> Users can see those priority values in pg_stat_replication.
> Isn't this confusing? If yes, it might be better to always assign 1 as
> the priority, for example.
> Any other?

Do we need to consider the sorting method and the selecting k-th
latest LSN method?


Masahiko Sawada
NTT Open Source Software Center

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

Reply via email to