Skip to content
  • bin.x.su@oracle.com's avatar
    137f3e51
    BUG#16559254 FTS OBJECT ID DOES NOT USE HEXADECIMAL ON WINDOWS · 137f3e51
    bin.x.su@oracle.com authored
    == Analysis ==
    Windows format string is wrong, we should use "%016llx" rather than "%016llu"
    
    == Solution ==
    This patch will force all the aux tables to be renamed from "%016llu" format
    to "%016llx" only in Windows, keeping aux table names in Linux unchanged.
    
    Suppose all users who want to upgrade server will start the new server in
    read/write mode at the first time.
    
    Macro definitions are fixed first. Only one format "%016llx" will be used in
    fts_write(read)_object_id. And a table flags2 bit named
    DICT_TF2_FTS_AUX_HEX_NAME(HEX_NAME for short) is introduced which is used in
    the following way:
    1. If an aux table is renamed to "%016llx" format, set this aux table's
       flags2 with this bit. And if a parent table's aux tables are all renamed
       to "%016llx" format, set this parent table's flags2 with this bit. (Win)
    2. Set a parent table and all its aux tables' flags2 with this bit. (Linux)
    3. For all existing tables, this bit will be set for a parent table and all
       its aux tables, or none of them will be set. (Win/Linux)
    4. Set all new created and/or altered tables(aux tables)' flags2 with this
       bit. (Win/Linux)
    
    During the upgrade which only happens in Windows, we do these:
    1. sort all aux tables by their parent table IDs in case rename will fail.
    2. prepare a vector(V) to store aux tables which need to be renamed.
    3. try to open an aux table, whose table id is always correct.
    4. if fail to open the table or the table opened is a different table, skip
       this table.
    5. if the opened aux table doesn't have flags2 set with HEX_NAME, convert
       all ids on it to the correct ones.
    6. then we can open the parent table with a correct id.
    7. do things like original codes do.
    8. if this aux table won't be dropped, put this aux table to V.
    9. if all aux tables belonging to the same parent table are collected,
       try to rename them(stored in V) in a batch mode. If all rename operations
       succeed, set all flags2 with HEX_NAME, otherwise, rollback all the rename
       operations for this parent table.
    
    For Linux, It needs to set the flags2 for every parent and aux tables.
    
    If the server crashes during the upgrade, all those aux common tables, which
    have already been renamed, should be renamed to their original names while
    renamed index tables will roll back automatically. Otherwise, these tables'
    names in innodb_sys_tables will not consist with their data file's names.
    After that, the server can upgrade again when it restart.
    
    In case the upgrade fails, the server can access both tables with AUX_HEX_NAME
    set and without AUX_HEX_NAME set. The tables fail to rename will upgrade
    themselves when server restart. One restriction is that we can't do in-place
    add fulltext to those tables fail to rename(we will get an new error from
    server), to make sure that either the AUX_HEX_NAME flags are set in parent
    table and its aux tables or not. Other DDL operations are allowed.
    
    rb#2396, approved by Jimmy.
    137f3e51
    BUG#16559254 FTS OBJECT ID DOES NOT USE HEXADECIMAL ON WINDOWS
    bin.x.su@oracle.com authored
    == Analysis ==
    Windows format string is wrong, we should use "%016llx" rather than "%016llu"
    
    == Solution ==
    This patch will force all the aux tables to be renamed from "%016llu" format
    to "%016llx" only in Windows, keeping aux table names in Linux unchanged.
    
    Suppose all users who want to upgrade server will start the new server in
    read/write mode at the first time.
    
    Macro definitions are fixed first. Only one format "%016llx" will be used in
    fts_write(read)_object_id. And a table flags2 bit named
    DICT_TF2_FTS_AUX_HEX_NAME(HEX_NAME for short) is introduced which is used in
    the following way:
    1. If an aux table is renamed to "%016llx" format, set this aux table's
       flags2 with this bit. And if a parent table's aux tables are all renamed
       to "%016llx" format, set this parent table's flags2 with this bit. (Win)
    2. Set a parent table and all its aux tables' flags2 with this bit. (Linux)
    3. For all existing tables, this bit will be set for a parent table and all
       its aux tables, or none of them will be set. (Win/Linux)
    4. Set all new created and/or altered tables(aux tables)' flags2 with this
       bit. (Win/Linux)
    
    During the upgrade which only happens in Windows, we do these:
    1. sort all aux tables by their parent table IDs in case rename will fail.
    2. prepare a vector(V) to store aux tables which need to be renamed.
    3. try to open an aux table, whose table id is always correct.
    4. if fail to open the table or the table opened is a different table, skip
       this table.
    5. if the opened aux table doesn't have flags2 set with HEX_NAME, convert
       all ids on it to the correct ones.
    6. then we can open the parent table with a correct id.
    7. do things like original codes do.
    8. if this aux table won't be dropped, put this aux table to V.
    9. if all aux tables belonging to the same parent table are collected,
       try to rename them(stored in V) in a batch mode. If all rename operations
       succeed, set all flags2 with HEX_NAME, otherwise, rollback all the rename
       operations for this parent table.
    
    For Linux, It needs to set the flags2 for every parent and aux tables.
    
    If the server crashes during the upgrade, all those aux common tables, which
    have already been renamed, should be renamed to their original names while
    renamed index tables will roll back automatically. Otherwise, these tables'
    names in innodb_sys_tables will not consist with their data file's names.
    After that, the server can upgrade again when it restart.
    
    In case the upgrade fails, the server can access both tables with AUX_HEX_NAME
    set and without AUX_HEX_NAME set. The tables fail to rename will upgrade
    themselves when server restart. One restriction is that we can't do in-place
    add fulltext to those tables fail to rename(we will get an new error from
    server), to make sure that either the AUX_HEX_NAME flags are set in parent
    table and its aux tables or not. Other DDL operations are allowed.
    
    rb#2396, approved by Jimmy.
Loading