Hello, > Er, I am not sure I follow here. The idea proposed was to define a > string formatted with some infra-language within the existing GUC > s_s_names.
I am sorry, I misunderstood. I thought the "language" approach meant use of hooks and module. As you mentioned the first step would be to reach the consensus on the method. If I understand correctly, s_s_names should be able to define: - a count of sync rep from a given group of names ex : 2 from A,B,C. - AND condition: Multiple groups and count can be defined. Ex: 1 from X,Y AND 2 from A,B,C. In this case, we can give the same priority to all the names specified in a group. The standby_names cannot be repeated across groups. Robert had also talked about a little more complex scenarios of choosing either A or both B and C. Additionally, preference for a standby could also be specified. Ex: among A,B and C, A can have higher priority and would be selected if an standby with name A is connected. This can make the language very complicated. Should all these scenarios be covered in the n-sync selection or can we start with the basic 2 and then update later? Thanks & Regards, Beena Emerson ----- -- Beena Emerson -- View this message in context: http://postgresql.nabble.com/Support-for-N-synchronous-standby-servers-take-2-tp5849384p5849736.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