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