Skip to content
  • Sivert Sorumgard's avatar
    0336f52b
    Bug#27864515: CRASH WITH ALTER TABLE .. RENAME INDEX .. ASSERT INDEX != NULLPTR · 0336f52b
    Sivert Sorumgard authored
    For InnoDB, a truly self referencing FK (a column 'c'  in table
    't' referencing column 'c' in table 't') with only one associated
    index could be added in an ALTER statement, and made succeeding
    index related ALTER operations fail with an assert. Previous MySQL
    server versions reject this by requiring supporting and parent
    indexes to be to different. This used to be enforced by the SE,
    but since the process of choosing supporting and parent indexes
    is now done at the SQL layer, the implementation of this check
    must also be done at the SQL layer.
    
    Since there are differences in the storage engines support in this
    area, a new handlerton foreign key flag is introduced to mark
    engines that do not allow the supporting and parent indexes to be
    the same.
    
    This patch re-establishes the previous behavior by explicitly
    disregarding the supporting index when candidate parent indexes
    are considered at the SQL layer, if the storage engine requires
    these to be different.
    
    Change-Id: I6f78d5576161b7f3656589efcfde94f2db7dbec0
    0336f52b
    Bug#27864515: CRASH WITH ALTER TABLE .. RENAME INDEX .. ASSERT INDEX != NULLPTR
    Sivert Sorumgard authored
    For InnoDB, a truly self referencing FK (a column 'c'  in table
    't' referencing column 'c' in table 't') with only one associated
    index could be added in an ALTER statement, and made succeeding
    index related ALTER operations fail with an assert. Previous MySQL
    server versions reject this by requiring supporting and parent
    indexes to be to different. This used to be enforced by the SE,
    but since the process of choosing supporting and parent indexes
    is now done at the SQL layer, the implementation of this check
    must also be done at the SQL layer.
    
    Since there are differences in the storage engines support in this
    area, a new handlerton foreign key flag is introduced to mark
    engines that do not allow the supporting and parent indexes to be
    the same.
    
    This patch re-establishes the previous behavior by explicitly
    disregarding the supporting index when candidate parent indexes
    are considered at the SQL layer, if the storage engine requires
    these to be different.
    
    Change-Id: I6f78d5576161b7f3656589efcfde94f2db7dbec0
Loading