On Mon, May 18, 2015 at 9:40 AM, Beena Emerson <memissemer...@gmail.com> wrote: >> 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?
If it were me, I'd just go implement a scanner using flex and a parser using bison and use that to parse the format I suggested before, or some similar one. This may sound hard, but it's really not: I put together the patch that became commit 878fdcb843e087cc1cdeadc987d6ef55202ddd04 in just a few hours. I don't see why this would be particularly harder. Then instead of arguing about whether some stop-gap implementation is good enough until we do the real thing, we can just have the real thing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
