Re: Support for N synchronous standby servers - take 2

On Thu, Jun 25, 2015 at 12:15 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Wed, Jun 24, 2015 at 11:30 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Fri, May 15, 2015 at 9:18 PM, Michael Paquier
>> <michael(dot)paquier(at)gmail(dot)com> wrote:
>>> On Fri, May 15, 2015 at 8:55 PM, Beena Emerson <memissemerson(at)gmail(dot)com> wrote:
>>>> There was a discussion on support for N synchronous standby servers started
>>>> by Michael. Refer
>>>> http://archives.postgresql.org/message-id/CAB7nPqR9c84ig0ZUvhMQAMq53VQsD4rC82vYci4Dr27PVOFf9w@mail.gmail.com
>>>> . The use of hooks and dedicated language was suggested, however, it seemed
>>>> to be an overkill for the scenario and there was no consensus on this.
>>>> Exploring GUC-land was preferred.
>>>
>>> Cool.
>>>
>>>> Please find attached a patch, built on Michael's patch from above mentioned
>>>> thread, which supports choosing different number of nodes from each set i.e.
>>>> k nodes from set 1, l nodes from set 2, so on.
>>>> The format of synchronous_standby_names has been updated to standby name
>>>> followed by the required count separated by hyphen. Ex: 'aa-1, bb-3'. The
>>>> transaction waits for all the specified number of standby in each group. Any
>>>> extra nodes with the same name will be considered potential. The special
>>>> entry * for the standby name is also supported.
>>>
>>> I don't think that this is going in the good direction, what was
>>> suggested mainly by Robert was to use a micro-language that would
>>> allow far more extensibility that what you are proposing. See for
>>> example CA+TgmobPWoeNMMEpfx0jWRvQufxVbqRv26Ezq_XHk21GxrXo9w(at)mail(dot)gmail(dot)com
>>> for some ideas.
>>
>> Doesn't this approach prevent us from specifying the "potential" synchronous
>> standby server? For example, imagine the case where you want to treat
>> the server AAA as synchronous standby. You also want to use the server BBB
>> as synchronous standby only if the server AAA goes down. IOW, you want to
>> prefer to the server AAA as synchronous standby rather than BBB.
>> Currently we can easily set up that case by just setting
>> synchronous_standby_names as follows.
>>
>> synchronous_standby_names = 'AAA, BBB'
>>
>> However, after we adopt the quorum commit feature with the proposed
>> macro-language, how can we set up that case? It seems impossible...
>> I'm afraid that this might be a backward compatibility issue.
>
> Like that:
> synchronous_standby_names = 'AAA, BBB'
> The thing is that we need to support the old grammar as well to be
> fully backward compatible,

Yep, that's an idea. Supporting two different grammars is a bit messy, though...
If we merge the "priority" concept to the quorum commit,
that's better. But for now I have no idea about how we can do that.

> 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.

Regards,

--
Fujii Masao