On Jun 12, 2013 2:02 AM, "Tatsuo Ishii" <is...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
