> 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.
Can you elaborate more on this? Suppose streaming replication primary commits xid = X at time Y. Later on a standy receives WAL including tx X and commit it at time Y + 3 seconds. How can a parallel query execution (which uses snapshot including X) on the standby be delayed until Y + 3 seconds? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
