Skip site navigation (1) Skip section navigation (2)

Re: PostgreSQL-R

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "Mikheev, Vadim" <VMIKHEEV(at)sectordata(dot)com>
Cc: "PostgreSQL Hackets (E-mail)" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PostgreSQL-R
Date: 2002-12-27 05:55:52
Message-ID: 200212270555.gBR5tqL22590@candle.pha.pa.us (view raw or flat)
Thread:
Lists: 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(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

In response to

pgsql-hackers by date

Next:From: Kevin BrownDate: 2002-12-27 08:04:36
Subject: Re: MOVE strangeness
Previous:From: Vadim MikheevDate: 2002-12-27 05:50:06
Subject: Vacation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group