Horton

Thread

  1. PostgreSQL-R

    Vadim Mikheev <vmikheev@sectordata.com> — 2002-12-20T19:45:57Z

    > 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

  2. Re: PostgreSQL-R

    darren@up.hrcoxmail.com — 2002-12-22T01:58:58Z

    >
>
>
>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?
>

We haven't put those hooks in yet, so the current version is master/slave.  

>
>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?
>

Seems like a good idea to me, but we won't know for sure until we 
implement the multi-
master hooks.  

Thanks,

Darren

>
>
>

  3. Re: PostgreSQL-R

    Vadim Mikheev <vmikheev@sectorbase.com> — 2002-12-24T06:33:01Z

    > > It seems that locking tuples via LockTable at Phase 1 is not
> > required anymore, right?
>
> We haven't put those hooks in yet, so the current version is master/slave.

So, you are not going to use any LockTable in Phase 1 on master right
now but you still need some LockTable in Phase 3 on slaves. Are you
going to use pg lock manager table in Phase 3? Shouldn't "ordering" in
Phase 3 be implemented using special LockTable, totally separated from
pg lock manager? (if it's right that Phase 1 doesn't require Phase 3
LockTable at all.)

> > 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.

And it would increase commit chances for long running transactions:
due to async notification to other nodes about changes made by
transaction, short transactions may have noticeably higher chances
to commit ... and abort conflicting long transactions.

> Seems like a good idea to me, but we won't know for sure until we
> implement the multi-master hooks.

Is it about periodic Phases 2 & 3 or about using Phase 3' LockTable
in Phase 1? The first one definitely can wait but the second one should
be resolved before merging pg-r code with main CVS, imo.

Vadim

  4. Re: PostgreSQL-R

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-12-27T05:55:52Z

    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, Pennsylvania 19073