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.