Re: PostgreSQL-R - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: PostgreSQL-R
Date
Msg-id 005a01c2ab16$4eff0040$2d498240@home
Whole thread Raw
In response to PostgreSQL-R  ("Mikheev, Vadim" <VMIKHEEV@sectordata.com>)
List pgsql-hackers
> > 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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: about data type id
Next
From: "Sander Steffann"
Date:
Subject: RPMS for RedHat 6.2/7.3/8.0 ready