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.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com