Re: Big 7.4 items

Поиск
Список
Период
Сортировка
От
Тема Re: Big 7.4 items
Дата
Msg-id 20021213211237.UQIU25316.lakecmmtao01.coxmail.com@lakecmmtab01
обсуждение исходный текст
Ответ на Big 7.4 items  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Big 7.4 items  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Big 7.4 items
Следующее
От:
Дата:
Сообщение: Re: Big 7.4 items