-
Aditya A authored
PROBLEM ------- 1) Collation change on the column is a inplace alter operation.(if no index on the column) 2) The column information is stored in dict_table_t->cols[] array which is a in memory structure. 3) During inplace alter, the collation is changed in the DD table but innodb ignores the collation change since there is no change in data ,but it is necessary to change it in the in memory object dict_table_t->col[].prtype,but in this case this was only happening with CHAR datatype. 4) So for varchar datatype the memory object is not updated. When a index is created on this column , the new index takes the column information from the in memory object and copies the stale precision type. 5) When the search is made on the index the comparison of data happens with the previous collation and may lead to wrong result. FIX --- 1) For varchar and text datatypes , make sure to update precision type in the memory object during inplace commit operation. RB: #24689 Reviewed by : Debarun Banerjee <debarun.banerjee@oracle.com>
Aditya A authoredPROBLEM ------- 1) Collation change on the column is a inplace alter operation.(if no index on the column) 2) The column information is stored in dict_table_t->cols[] array which is a in memory structure. 3) During inplace alter, the collation is changed in the DD table but innodb ignores the collation change since there is no change in data ,but it is necessary to change it in the in memory object dict_table_t->col[].prtype,but in this case this was only happening with CHAR datatype. 4) So for varchar datatype the memory object is not updated. When a index is created on this column , the new index takes the column information from the in memory object and copies the stale precision type. 5) When the search is made on the index the comparison of data happens with the previous collation and may lead to wrong result. FIX --- 1) For varchar and text datatypes , make sure to update precision type in the memory object during inplace commit operation. RB: #24689 Reviewed by : Debarun Banerjee <debarun.banerjee@oracle.com>
Loading