Merge lp:~pbeaman/akiban-persistit/fix-1056489-mvv-step-visibility into lp:akiban-persistit
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Peter Beaman | ||||
Approved revision: | 370 | ||||
Merged at revision: | 371 | ||||
Proposed branch: | lp:~pbeaman/akiban-persistit/fix-1056489-mvv-step-visibility | ||||
Merge into: | lp:akiban-persistit | ||||
Diff against target: |
231 lines (+148/-18) 3 files modified
src/main/java/com/persistit/MVV.java (+17/-5) src/test/java/com/persistit/Bug1056489Test.java (+125/-0) src/test/java/com/persistit/MVVTest.java (+6/-13) |
||||
To merge this branch: | bzr merge lp:~pbeaman/akiban-persistit/fix-1056489-mvv-step-visibility | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Akiban Build User | Needs Fixing | ||
Nathan Williams | Approve | ||
Review via email: mp+126522@code.launchpad.net |
Description of the change
Fix bug 1056489 MVV and step visibility and pruning errors. This bug arises to incorrect handling of MVV versions when a single transaction performs two or more updates at different step numbers, and when those updates are not ordered by increasing step value. For example, inserting a value with step=2 and then removing the value with step=1 will result in an MVV that sometimes yields the correct result and sometimes appears to have no value.
The assumption in MVV#storeVersion that versions could only arrive in increasing version-handle order was wrong in this case. The primary change is to allow step #01 to be inserted into the MVV at the correct location with respect to step #02 rather than at the end. A new unit test based on Nathan's original investigation code has also been added.
Keeping the mvv array in strict order is probably simplest. Looks good.