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 g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services and Support www.2ndQuadrant.us -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
