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