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