Re: PostgreSQL-R

FYI, I think we are going to need two-phase commit, at least to
implement distributed transactions. I will add it to the TODO list.

---------------------------------------------------------------------------

Mikheev, Vadim wrote:
> > 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
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073