Merge lp:~tjoneslo/akiban-server/fix-bug-1199111 into lp:~akiban-technologies/akiban-server/trunk
Status: | Merged |
---|---|
Approved by: | Thomas Jones-Low |
Approved revision: | 2713 |
Merged at revision: | 2721 |
Proposed branch: | lp:~tjoneslo/akiban-server/fix-bug-1199111 |
Merge into: | lp:~akiban-technologies/akiban-server/trunk |
Diff against target: |
500 lines (+261/-41) 8 files modified
src/main/java/com/akiban/server/service/dxl/AlterTableHelper.java (+1/-1) src/main/java/com/akiban/server/service/dxl/BasicDDLFunctions.java (+2/-2) src/main/java/com/akiban/server/store/AbstractSchemaManager.java (+74/-14) src/main/java/com/akiban/server/store/AbstractStore.java (+3/-4) src/main/java/com/akiban/server/store/PersistitStoreSchemaManager.java (+2/-18) src/main/java/com/akiban/server/store/SchemaManager.java (+4/-1) src/test/java/com/akiban/server/service/is/BasicInfoSchemaTablesServiceImplTest.java (+1/-1) src/test/resources/com/akiban/sql/pg/yaml/bugs/test-bug-1199111.yaml (+174/-0) |
To merge this branch: | bzr merge lp:~tjoneslo/akiban-server/fix-bug-1199111 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Nathan Williams | Approve | ||
Review via email: mp+177246@code.launchpad.net |
Description of the change
Fix bug 1199111 - Where an failed alter table followed by a second one on a group table would return an incorrect error, and then fail to allow any further alters on the table(s) in the group.
This bug was a little subtler than described in the bug 1199111 report.
The core change is in the AbstractSchemaM
The subtle problem is that the table version stored with the table needs to be updated immediately so that when the AIS is frozen and stored, it has the correct table version. But the tableVersionMap (used for lock checking) is now deferred until much later. This mostly isn't a problem because the tables affected by the Alter DDL are locked, meaning nothing else is reading them.
The exception is the tables used in group indexes which affected indirectly by a table change. That is, if there is a group with tables A, B, C, and a group index on all three tables, and the ALTER changes a column in table C which is also in the group index. The group index maintenance is to drop the group index, perform the table change, then recreate the group index. In this case we know that the group index will be re-created on tables A and B (and possibly C), but those tables are not locked during the DDL processing. So don't change the table version on tables A and B while doing the group index maintenance.
AbstractSchemaM
As described above, the dropIndexes() now skips the bumpTableVersion process if this is part of the group index drop/create. Add a flag to the dropIndex to indicate this. This has a refactoring change to the callers.
PersistitStoreS
AlterTableHelper - dropAffectedGro
test-bug-1199111.yaml - tests of the original problem, with variations.
This looks good.
I think we can move the PSSM#trackBumpT ableVersion( ) to the base class though. Just need to pass TransactionService to it. That way the FDBSchemaManager gets in on the fun for free.
Feel free to big-A after that.