Re: Issues with Quorum Commit

Tom Lane wrote:
> How are you going to "mark the standby as degraded"?  The
> standby can't keep that information, because it's not even connected
> when the master makes the decision.
From a high level, I'm assuming only that the master has a list in 
memory of the standby system(s) it believes are up to date, and that it 
is supposed to commit to synchronously.  When I say mark as degraded, I 
mean that the master merely closes whatever communications channel it 
had open with that system and removes the standby from that list.

If that standby now reconnects again, I don't see how resolving what 
happens at that point is any different from when a standby is first 
started after both systems were turned off.  If the standby is current 
with the data available on the master when it has an initial 
conversation, great; it's now available for synchronous commit too 
then.  If it's not, it goes into a catchup mode first instead.  When the 
master sees you're back to current again, if you're on the list of sync 
servers too you go back onto the list of active sync systems.

There's shouldn't be any state information to save here.  If the master 
and standby can't figure out if they are in or out of sync with one 
another based on the conversation they have when they first connect to 
one another, that suggests to me there needs to be improvements made in 
the communications protocol they use to exchange messages. 

-- 
Greg Smith, 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services and Support  www.2ndQuadrant.us