Re: Behaviour of take over the synchronous replication

On Wed, Aug 28, 2013 at 5:51 AM, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
>> What is happening here is that incase of '*' as priority of both
>> are same, system will choose whichever comes in list of
>> registered standby's first (list is maintained in structure
>> WalSndCtl). Each standby is registered with WalSndCtl when a new
>> WALSender is started in function InitWalSenderSlot(). As 'AAA'
>> has been registered first it becomes preferred sync standby even
>> if priorities of both are same. When 'AAA' goes down, it marks
>> that Slot entry as free (by setting pid=0 in function
>> WalSndKill), now when 'AAA' comes back again, it gets that free
>> Slot entry and again becomes preferred sync standby.
>
> So, when a user says they don't care about which standby is in sync
> mode, the system can decide (based on internal implementation
> details not visible to the user) that any node which comes online
> could now become the sync node, and freeze commits on the source
> database until that newly added node catches up? Or does the
> existing sync node continue in that role until the new "preferred"
> node is caught up?
Existing sync node continue in that role until the new preferred node
is streamed.
For example, When 'AAA' comes back again and reached consistency
point, 'AAA' wal sender state is 'catchup'.
IWO 'AAA' doesn't has authority to operate the queue.
'BBB' server is preferred sync standby server while 'AAA' wal sender
state is 'catchup'.
So even if user execute query, master server doesn't freeze commits
When 'AAA' walsender state become 'streaming', 'AAA' becomes preferred
sync standby again.

Regards,

-------
Sawada Masahiko