Re: Support for N synchronous standby servers - take 2
От | Simon Riggs |
---|---|
Тема | Re: Support for N synchronous standby servers - take 2 |
Дата | |
Msg-id | CANP8+j+7aPHjtKP+tB9dtYWSiYvni8DAibNBV6n4kCqv6nYWBQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Support for N synchronous standby servers - take 2 (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Support for N synchronous standby servers - take 2
Re: Support for N synchronous standby servers - take 2 |
Список | pgsql-hackers |
On 25 June 2015 at 05:01, Michael Paquier <michael.paquier@gmail.com> wrote:
--
On Thu, Jun 25, 2015 at 12:57 PM, Fujii Masao wrote:
> On Thu, Jun 25, 2015 at 12:15 PM, Michael Paquier wrote:
>> and that's actually equivalent to that in
>> the grammar: 1(AAA,BBB,CCC).
>
> I don't think that they are the same. In the case of 1(AAA,BBB,CCC), while
> two servers AAA and BBB are running, the master server may return a success
> of the transaction to the client just after it receives the ACK from BBB.
> OTOH, in the case of AAA,BBB, that never happens. The master must wait for
> the ACK from AAA to arrive before completing the transaction. And then,
> if AAA goes down, BBB should become synchronous standby.
Ah. Right. I missed your point, that's a bad day... We could have
multiple separators to define group types then:
- "()" where the order of acknowledgement does not matter
- "[]" where it does not.
You would find the old grammar with:
1[AAA,BBB,CCC]
Let's start with a complex, fully described use case then work out how to specify what we want.
I'm nervous of "it would be good ifs" because we do a ton of work only to find a design flaw.
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: