Re: PostgreSQL-R
От | Bruce Momjian |
---|---|
Тема | Re: PostgreSQL-R |
Дата | |
Msg-id | 200212270555.gBR5tqL22590@candle.pha.pa.us обсуждение исходный текст |
Ответ на | PostgreSQL-R ("Mikheev, Vadim" <VMIKHEEV@sectordata.com>) |
Список | pgsql-hackers |
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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: