Bug #51787 | Assertion `(n % 4) == 0' on slave upon INSERT into a table with UTF32 charset | ||
---|---|---|---|
Submitted: | 6 Mar 2010 2:34 | Modified: | 15 Mar 2010 12:31 |
Reporter: | Elena Stepanova | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Row Based Replication ( RBR ) | Severity: | S2 (Serious) |
Version: | mysql-next-mr-bugfixing | OS: | Any |
Assigned to: | Luis Soares | CPU Architecture: | Any |
[6 Mar 2010 2:34]
Elena Stepanova
[10 Mar 2010 17:34]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/102922 3119 Luis Soares 2010-03-10 Fix for BUG#51716 and BUG#51787. In BUG#51787 we were using the wrong charset to print out the data. We were using the field charset for the string that would hold the information. This caused the assertion, because the string length was not aligned with UTF32 bytes requirements for storage. We fix this by using &my_charset_latin1 in the string object instead of the field->charset(). As a side-effect, we needed to extend the show_sql_type interface so that it took the field charset is now passed as a parameter, so that one is able to calculate the correct field size. In BUG#51716 we had issues with Field_string::pack and Field_string::unpack. When packing, the length was incorrectly calculated. When unpacking, the padding the string would be padded with the wrong bytes (a few bytes less than it should). We fix this by resorting to charset abstractions (functions) that calculate the correct length when packing and pad correctly the string when unpacking.
[10 Mar 2010 22:20]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/102945 3120 Luis Soares 2010-03-10 Fix for BUG#51716 and BUG#51787: test case improvements. Split rpl_row_charset into: - rpl_row_utf16. - rpl_row_utf32. This way these tests can run independently if server supports either one of the charsets but not both. Cleaned up rpl_row_utf32 which had a spurious instruction: -- let $reset_slave_type_conversions= 0
[11 Mar 2010 8:00]
Alexander Barkov
The patch http://lists.mysql.com/commits/102922 and the post-fix http://lists.mysql.com/commits/102945 look fine.
[11 Mar 2010 11:08]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/102982 3814 Luis Soares 2010-03-11 [merge] Fix for BUG#51716 and BUG#51787: merge to 6.0-codebase-bugfixing. Manually merged tests changes: - rpl_row_utf16 Removed the empty INSERT! Because of BUG@49100, the test would fail. - rpl_row_utf32 Removed the warnings from the result file. Maximum key size is 1332 bytes in 6.0, thence we don't get warnings.
[12 Mar 2010 18:11]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100312180926-0emfjrj8e9xnvl8h) (version source revid:alik@sun.com-20100312180447-2r0ak22y13s05134) (merge vers: 6.0.14-alpha) (pib:16)
[12 Mar 2010 18:12]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100312180838-rk60kn38g0qwt78n) (version source revid:alik@sun.com-20100312180435-wk7nvsbfntfus5bu) (pib:16)
[12 Mar 2010 18:22]
Bugs System
Pushed into 5.5.3-m3 (revid:alik@sun.com-20100312181131-0b7v8r2htpd9jz2a) (version source revid:alik@sun.com-20100312181131-0b7v8r2htpd9jz2a) (merge vers: 5.5.3-m3) (pib:16)
[15 Mar 2010 12:31]
Jon Stephens
Documented bugfic in the 5.5.3 and 6.0.14 changelogs as follows: When using the row-based or mixed replication format with a debug build of the MySQL server, inserts into columns using the UTF32 character set on the master caused the slave to crash. Closed.