Re: write ahead logging in standby (streaming replication)

Hi,

Quoting "Greg Smith" <greg(at)2ndquadrant(dot)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