Re: Support for N synchronous standby servers - take 2 - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Support for N synchronous standby servers - take 2
Date
Msg-id CAHGQGwEyPv=EN7g=QmuVWNubxEuKGbVqca_VojepmT7aX+0_5g@mail.gmail.com
Whole thread Raw
In response to Re: Support for N synchronous standby servers - take 2  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Support for N synchronous standby servers - take 2  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Fri, May 15, 2015 at 9:18 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Fri, May 15, 2015 at 8:55 PM, Beena Emerson <memissemerson@gmail.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@mail.gmail.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.

Or we should extend the proposed micro-language so that it also can handle
the priority of each standby servers? Not sure that's possible, though.

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: UPSERT on partition
Next
From: Robert Haas
Date:
Subject: Re: UPSERT on partition