Re: Behaviour of take over the synchronous replication

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Behaviour of take over the synchronous replication
Date: 2013-08-27 20:51:00
Message-ID: 1377636660.4676.YahooMailNeo@web162903.mail.bf1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2013-08-27 21:04:00 Re: Does larger i/o size make sense?
Previous Message Pavel Stehule 2013-08-27 20:36:58 Re: PL/pgSQL PERFORM with CTE