PostgreSQL-R

> 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