From: | <darren(at)up(dot)hrcoxmail(dot)com> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | 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 21:12:37 |
Message-ID: | 20021213211237.UQIU25316.lakecmmtao01.coxmail.com@lakecmmtab01 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> It is asynchronous without the need of 2 phase commit. It is group
> communication based and requires the group communication system to
> guarantee total order. The tricky part is, that the local transaction
> must be on hold until the own commit message comes back without a prior
No, It holds until it's own Writeset comes back. Commits
and then send a commit message on the simple channel, so
commits don't wait for ordered writesets.
Remember total order guarantees if no changes in front of
the local changes conflict, the local changes can commit.
> lock conflict by a replication transaction. If such a lock confict
> occurs, the replication transaction wins and the local transaction rolls
> back.
Correct.
>
> The last time i was playing with spread (that was at Great Bridge in
> Norfolk), it was IMHO useless (for Postgres-R) because it sometimes
> dropped messages when the network load got too high. This occured
> without any indication, no error, nothing. This is not exactly what I
> understand as total order. I hope they have made some substantial
> progress on that.
>
I remember the TCL tester you set up, and having problems,
but I don't recall investigating what the problems were.
If you still have the code I can try and reproduce the
problem, and investigate it on the spread list.
Darren
From | Date | Subject | |
---|---|---|---|
Next Message | darren | 2002-12-13 21:18:01 | Re: Big 7.4 items |
Previous Message | Bruce Momjian | 2002-12-13 21:09:44 | Re: Big 7.4 items |