Hello Srinivas,

M2Y wrote:
Markus: It looks like the hybrid approach used by Postgres-R(as
described in that paper) is good.

Well, yeah. That's why am working on it ;-)

You are very welcome to download the patch and dig into the sources. See www.postgres-r.org for more information.

To answer your original question in more details:

Suppose there are two sites in the group, lets say, A and B and are
managing a database D. Two transactions TA and TB started in sites A
and B respectively, at nearly same time, wanted to update same row of
a table in the database. As, no locking structures and other
concurrency handling structures are replicated each will go ahead and
do the modifications in their corresponding databases and sends the
writeset.

Correct so far. Note that both transactions might have applied changes, but they have not committed, yet.

In eager mode we rely on the Group Communication System to deliver these two changesets [1] in the same order on both nodes. Let's say both receive TA's changeset first, then TB's.

The backend which processed TA on node A can commit, because its changes don't conflict with anything else. The changeset of TB is forwarded to a helper backend, which tries to apply its changes. But the helper backend detects the conflict against TA and aborts (because it knows TA takes precedence on all other nodes as well).

On node B, the backend which processed TB has to wait with its commit, because another changeset, namely TA's came in first. For that changeset a helper backend is started as well, which applies the changes of TA. During application of changes, that helper backend detects a conflict against the (yet uncommitted) changes of TB. As it knows its transaction TA takes precedence over TB (on all other nodes as well), it tells TB to abort and continues applying its own changes.

I hope that was an understandable explanation.

Regards

Markus Wanner


[1]: In the original Postgres-R paper, these are called writesets. But in my implementation, I've altered its meaning somewhat. Because of that (and because I admittedly like "changeset" better), I've decided to call them changesets now...

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to