On 01/08/2014 03:27 PM, Tom Lane wrote: > Good point, but C can't solve this for you just by logging. If C was the > first to go down, it has no way to know whether A and B committed more > transactions before dying; and it's unlikely to have logged its own crash, > either.
Sure. But if we *knew* that C was not in synchronous mode when it went down, then we'd expect some data loss. As you point out, though, the converse is not true; even if C was in sync mode, we don't know that there's been no data loss, since B could come back up as a sync replica before going down again. > What we lack, and should work on, is a way for sync mode to have M larger > than one. AFAICS, right now we'll report commit as soon as there's one > up-to-date replica, and some high-reliability cases are going to want > more. Yeah, we talked about having this when sync rep originally went in. It involves a LOT more bookeeping on the master though, which is why nobody has been willing to attempt it -- and why we went with the single-replica solution in the first place. Especially since most people who want "quorum sync" really want MM replication anyway. "Sync N times" is really just a guarantee against data loss as long as you lose N-1 servers or fewer. And it becomes an even lower-availability solution if you don't have at least N+1 replicas. For that reason, I'd like to see some realistic actual user demand before we take the idea seriously. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
