Hi, Quoting "Greg Smith" <g...@2ndquadrant.com>:
"Synchronous replication - guarantees "zero data loss" by the means of atomic write operation, i.e. write either completes on both sides or not at all. Write is not considered complete until acknowledgement by both local and remote storage."
Note that a storage acknowledge (hopefully) guarantees durability, but it does not necessarily mean that the transactional changes are immediately visible on a remote node. Which is what you had in your definition.
My point is that there are at least three things that can run synchronously or not, WRT to distributed databases:
1. conflict detection and handling (for consistency) 2. storage acknowledgement (for durability) 3. effective application of changes (for visibility across nodes)
That last part is the critical one: "acknowledgement by both local and remote storage" is required before you can label something truly synchronous replication. In implementation terms, that means you must have both local and slave fsync calls finish to be considered truly synchronous. That part is not ambiguous at all.
I personally agree 100%. (Given it implies a congruent conflict handling *before* the disk write. Having conflicting transactional changes on the disk wouldn't help much at recovery time).
(And yes, this means I think the effective application of changes can be deferred. IMO the load balancer and/or the application should take care not to send transactions from the same session to different nodes).
"Semi-synchronous replication
..is plain non-sense to my ears. Either something is synchronous or it is not. No half, no semi, no virtual synchrony. To have any technical relevance, one needs to add *what* is synchronous and what not.
In that spirit I have to admit that the term 'eager' that I'm currently using to describe Postgres-R may not be any more helpful. I take it to mean synchrony of 1. and 2., but not 3.
Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
