>>> Please explain what you mean by the word "true" used here. >> In another word, "eager replication". > Do you mean something along these lines : > > "Most synchronous or eager replication solutions do conflict prevention, > while asynchronous solutions have to do conflict resolution. For instance, > if a record is changed on two nodes simultaneously, an eager replication > system would detect the conflict before confirming the commit and abort > one of the transactions. A lazy replication system would allow both > transactions to commit and run a conflict resolution during > resynchronization. " > > ?
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. > IMO it is possible to do this "easily" once BDR has reached the state > where you > can do streaming apply. > That is, you replay actions on other hosts as they > are logged, not after the transaction commits. Doing it this way you can > wait > any action to successfully complete a full circle before committing it > in source. > > Currently main missing part in doing this is autonomous transactions. > It can in theory be done by opening an extra backend for each incoming > transaction but you will need really big number of backends and also you > have extra overhead from interprocess communications. Thanks for a thought about the conflict resolution in BDR. BTW, if we seriously think about implementing the parallel query execution, we need to find a way to distribute data among each node, that requires partial copy of table. I thinl that would a big challenge for WAL based replication. -- 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
