Re: Big 7.4 items
От | Jan Wieck |
---|---|
Тема | Re: Big 7.4 items |
Дата | |
Msg-id | 3DFA56F0.B74DEACC@Yahoo.com обсуждение исходный текст |
Ответ на | Re: Big 7.4 items (<darren@up.hrcoxmail.com>) |
Список | pgsql-hackers |
darren@up.hrcoxmail.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. And that is IMHO not synchronous. C does not have to wait for A and B to finish the same tasks. If now at this very moment two new transactions query system A and system C (assuming A has not yet committed WS(C) while C has), they will get different data back (thanks to non-blocking reads). I think this is pretty asynchronous. It doesn't lead to inconsistencies, because the transaction on A cannot do something that is in conflict with the changes made by WS(C), since it's WS(A)2 will come back after WS(C) arrived at A and thus WS(C) arriving at A will cause WS(A)2 to rollback (WS used synonymous to Xact in this context). > > Hope that helps, > > Darren Hope this doesn't add too much confusion :-) Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-hackers по дате отправления: