From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | darren(at)up(dot)hrcoxmail(dot)com |
Cc: | Jan Wieck <JanWieck(at)Yahoo(dot)com>, shridhar_daithankar(at)persistent(dot)co(dot)in, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Big 7.4 items |
Date: | 2002-12-13 22:11:22 |
Message-ID: | 200212132211.gBDMBMU14075@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
darren(at)up(dot)hrcoxmail(dot)com wrote:
> >
> >
> > Darren, can you clarify this? Why does it send that message? How does
> > it allow commits not to wait for ordered writesets?
> >
>
> There are two channels. One for total order writesets
> (changes to the DB). The other is simple order for
> aborts, commits, joins (systems joining the replica), etc.
> The simple channel is necessary, because we don't want to
> wait for total ordered changes to get an abort message and
> so forth. In some cases you might get an abort or a commit
> message before you get the writeset it refers to.
>
> Lets say we have systems A, B and C. Each one has some
> changes and sends a writeset to the group communication
> system (GSC). The total order dictates WS(A), WS(B), and
> WS(C) and the writes sets are recieved in that order at
> each system. Now C gets WS(A) no conflict, gets WS(B) no
> conflict, and receives WS(C). Now C can commit WS(C) even
> before the commit messages C(A) or C(B), because there is no
> conflict.
Oh, so C doesn't apply A's changes until it see A's commit, but it can
continue with its own changes because there is no conflict?
--
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
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2002-12-13 23:38:33 | Re: Big 7.4 items |
Previous Message | Jan Wieck | 2002-12-13 21:53:52 | Re: Big 7.4 items |