Re: Exposing the Xact commit order to the user
От | Heikki Linnakangas |
---|---|
Тема | Re: Exposing the Xact commit order to the user |
Дата | |
Msg-id | 4BFD8A13.7080106@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Exposing the Xact commit order to the user (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Exposing the Xact commit order to the user
|
Список | pgsql-hackers |
On 26/05/10 23:45, Heikki Linnakangas wrote: > On 26/05/10 23:32, Jan Wieck wrote: >> Consider two transactions A and B that due to transaction batching >> between snapshots get applied together. Let the order of actions be >> >> 1. A starts >> 2. B starts >> 3. B selects a row for update, then updates the row >> 4. A tries to do the same and blocks >> 5. B commits >> 6. A gets the lock, the row, does the update >> 7. A commits >> >> If Slony (or Londiste) would not record the exact order of those >> individual row actions, then it would not have any idea if within that >> batch the action of B (higher XID) actually came first. Without that >> knowledge there is a 50/50 chance of getting your replica out of sync >> with that simple conflict. > > Hmm, I don't see how even a fully reliable WAL-logged commit-order log > would save you then. It seems that you need to not only know the > relative order of commits, but the order of commits relative to actions > within the transactions. I.e. in the above example it's not enough to > know that B committed before A, you also have to know that A updated the > row only after B committed. Ok, I think I understand it now. The commit order is enough, because replaying the actions in the order "all actions of B, then all actions of A" yields the same result. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: