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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
