On Jun 12, 2013 2:02 AM, "Tatsuo Ishii" <ishii@postgresql.org> wrote:
> No, I'm not talking about conflict resolution.
>
> From http://www.cs.cmu.edu/~natassa/courses/15-823/F02/papers/replication.pdf:
> ----------------------------------------------
> Eager or Lazy Replication?
> Eager replication:
> keep all replicas synchronized by updating all
> replicas in a single transaction
>
> Lazy replication:
> asynchronously propagate replica updates to
> other nodes after replicating transaction commits
> ----------------------------------------------
>
> Parallel query execution needs to assume that each node synchronized
> in a commit, otherwise the summary of each query result executed on
> each node is meaningless.
As far as I can see the lazy-eager terminology is based on a
multi-master configuration and doesn't really apply for PostgreSQL
streaming replication.
Parallel query execution doesn't require commits to synchronize all
nodes. Parallel execution needs consistent snapshots across all nodes.
In effect this means that nodes need to agree on commit ordering,
either total order or a partial order that accounts for causality.
Most applications also want the guarantee that once they receive
commit confirmation, next snapshot they take will consider their
transaction as committed.
Coincidentally getting cluster wide consistent snapshots and delaying
until some specific point in commit ordering is almost trivial to
solve with Commit Sequence Number based snapshot scheme that I
proposed.
Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de