On Thu, Jul 2, 2015 at 9:31 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Thu, Jul 2, 2015 at 5:44 PM, Beena Emerson <memissemer...@gmail.com> wrote: >> Hello, >> There has been a lot of discussion. It has become a bit confusing. >> I am summarizing my understanding of the discussion till now. >> Kindly let me know if I missed anything important. >> >> Backward compatibility: >> We have to provide support for the current format and behavior for >> synchronous replication (The first running standby from list s_s_names) >> In case the new format does not include GUC, then a special value to be >> specified for s_s_names to indicate that. >> >> Priority and quorum: >> Quorum treats all the standby with same priority while in priority behavior, >> each one has a different priority and ACK must be received from the >> specified k lowest priority servers. >> I am not sure how combining both will work out. >> Mostly we would like to have some standbys from each data center to be in >> sync. Can it not be achieved by quorum only? > > So you're wondering if there is the use case where both quorum and priority > are > used together? > > For example, please imagine the case where you have two standby servers > (say A and B) in local site, and one standby server (say C) in remote disaster > recovery site. You want to set up sync replication so that the master waits > for > ACK from either A or B, i.e., the setting of 1(A, B). Also only when either A > or B crashes, you want to make the master wait for ACK from either the > remaining local standby or C. On the other hand, you don't want to use the > setting like 1(A, B, C). Because in this setting, C can be sync standby when > the master craches, and both A and B might be very behind of C. In this case, > you need to promote the remote standby server C to new master,,, this is what > you'd like to avoid. > > The setting that you need is 1(1[A, C], 1[B, C]) in Michael's proposed > grammer. >
If we set the remote disaster recovery site up as synch replica, we would get some big latencies even though we use quorum commit. So I think this case Fujii-san suggested is a good configuration, and many users would want to use it. I tend to agree with combine quorum and prioritization into one GUC parameter while keeping backward compatibility. Regards, -- Sawada Masahiko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
