Shaun,
> PostgreSQL's implementation means the master will block until
> someone/something notices and tells it to stop waiting, or the slave
> comes back. For pretty much any high-availability environment, this is
> not viable. Based on that alone, I can't imagine a scenario where
> synchronous replication would be considered beneficial.
So there's an issue with the definition of "synchronous". What
"synchronous" in "synchronous replication" means is "guarantee zero data
loss or fail the transaction". It does NOT mean "master and slave have
the same transactional data at the same time", as much as that would be
great to have.
There are, indeed, systems where you'd rather shut down the system than
accept writes which were not replicated, or we wouldn't have the
feature. That just doesn't happen to fit your needs (nor, indeed, the
needs of most people who think they want SR).
"Total-consistency" replication is what I think you want, that is, to
guarantee that at any given time a read query on the master will return
the same results as a read query on the standby. Heck, *most* people
would like to have that. You would also be advancing database science
in general if you could come up with a way to implement it.
> slave. That's currently impossible because async replication is too
> slow, and sync is too fragile for reasons stated above.
So I'm unclear on why sync rep would be faster than async rep given that
they use exactly the same mechanism. Explain?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com