Re: Big 7.4 items - Mailing list pgsql-hackers

From
Subject Re: Big 7.4 items
Date
Msg-id 20021213211237.UQIU25316.lakecmmtao01.coxmail.com@lakecmmtab01
Whole thread Raw
In response to Big 7.4 items  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Big 7.4 items
List 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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Big 7.4 items
Next
From:
Date:
Subject: Re: Big 7.4 items