Re: Support for N synchronous standby servers - take 2

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.