On 01/08/2014 12:27 PM, Bruce Momjian wrote:
> I am glad Heikki and Simon agree, but I don't. ;-)
>
> The way that I understand it is that you might want durability, but
> might not want to sacrifice availability. Phrased that way, it makes
> sense, and notifying the administrator seems the appropriate action.
I think there's a valid argument to want things the other way, but I
find the argument not persuasive. In general, people who want
auto-degrade for sync rep either:
a) don't understand what sync rep actually does (lots of folks confuse
synchronous with simultaneous), or
b) want more infrastructure than we actually have around managing sync
replicas
Now, the folks who want (b) have a legitimate need, and I'll point out
that we always planned to have more features around sync rep, it's just
that we never actually worked on any. For example, "quorum sync" was
extensively discussed and originally projected for 9.2, only certain
hackers changed jobs and interests.
If we just did the minimal change, that is, added an "auto-degrade" GUC
and an alert to the logs each time the master server went into degraded
mode, as Heikki says we'd be loading a big foot-gun for a bunch of
ill-informed DBAs. People who want that are really much better off with
async rep in the first place.
If we really want auto-degrading sync rep, then we'd (at a minimum) need
a way to determine *from the replica* whether or not it was in degraded
mode when the master died. What good do messages to the master log do
you if the master no longer exists?
Mind you, being able to determine on the replica whether it was
synchronous or not when it lost communication with the master would be a
great feature to have for sync rep groups as well, and would make them
practical (right now, they're pretty useless). However, I seriously
doubt that someone is going to code that up in the next 5 days.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com