> http://www.cs.mcgill.ca/~kemme/papers/vldb00.html
Thanks for the link, Darren, I think everyone interested in discussion should read it. First, I like approach. Second, I don't understand why ppl oppose pg-r & 2pc. 2pc is just simple protocol to perform distributed commits *after* distributed conflicts were resolved. It says nothing about *how* to resolve conflicts. Commonly, distributed locks are used, pg-r uses GCS & kind of "batch" locking to order distributed transactions and serialize execution of conflicting ones. Actually, this serialization is the only drawback I see at the moment: due to "batching" of writes/locks pg-r will not allow execution of transactions from different sites in read committed mode - one of conflicting transactions will be aborted instead of waiting for abort/commit of another one, continuing execution after that. Because of resolving conflicts *before* commit pg-r is not async solution. But it's not true sync replication neither due to async commit (read Jan vs Darren discussion in http://archives.postgresql.org/pgsql-hackers/2002-12/msg00754.php). What's problem with using 2pc for commit in pg-r? We could make it optional (and can discuss it later). Next, pg-r was originally based on 6.4, so what was changed for current pg versions when MV is used for CC? It seems that locking tuples via LockTable at Phase 1 is not required anymore, right? Upon receiving local WS in Phase 3 local transaction should just check that there are no conflicting locks from remote transactions in LockTable and can commit after that. Remote transactions will not see conflicts from local ones in LockTable but will notice them during execution and will be able to abort local transactions. (I hope I didn't miss something here.) Also it seems that we could perform Phases 2 & 3 periodically during transaction execution. This would make WS smaller and conflicts between long running transactions from different sites would be resoved faster. Comments? Vadim _____________________________________________________ Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
