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? Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
