Re: Exposing the Xact commit order to the user - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Exposing the Xact commit order to the user
Date
Msg-id 4BFD8A13.7080106@enterprisedb.com
Whole thread Raw
In response to Re: Exposing the Xact commit order to the user  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Exposing the Xact commit order to the user
List 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 by date:

Previous
From: Jan Wieck
Date:
Subject: Re: Exposing the Xact commit order to the user
Next
From: Josh Berkus
Date:
Subject: Re: Idea for getting rid of VACUUM FREEZE on cold pages