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? GUC parameter: There are some arguments over the text format. However if we continue using this, specifying the number before the group is a more readable option than specifying it later. S_s_names = 3(A, (P,Q), 2(X,Y,Z)) is better compared to S_s_names = (A, (P,Q), (X,Y,Z) (2)) (3) Catalog Method: Is it safe to assume we may not going ahead with the Catalog approach? A system catalog and some built in functions to set the sync parameters is not viable because it can cause - promoted master to sync rep itself - changes to catalog may continuously wait for ACK from a down server. The main problem of unlogged system catalog is data loss during crash. JSON: I agree it would make GUC very complex and unreadable. We can consider using is as meta data. I think the only point in favor of JSON is to be able to set it using functions instead of having to edit and reload right? Identifying standby: The main concern for the current use of application_name seems to be that multiple standby with same name would form an intentional group (maybe across data clusters too?). I agree it would be better to have a mechanism to uniquely identify a standby and groups can be made using whatever method we use to set the sync requirements. Main concern seems to be about deciding which standby is to be promoted is a separate issue altogether. ----- -- Beena Emerson -- View this message in context: http://postgresql.nabble.com/Support-for-N-synchronous-standby-servers-take-2-tp5849384p5856216.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
