> 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.
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