| Bug #32462 | Replication of CHAR(64) field with utf8 encoding crashes under RBR | ||
|---|---|---|---|
| Submitted: | 16 Nov 2007 21:02 | Modified: | 28 Jan 2009 20:31 |
| Reporter: | Mats Kindahl | Email Updates: | |
| Status: | Duplicate | Impact on me: | |
| Category: | MySQL Server: Row Based Replication ( RBR ) | Severity: | S1 (Critical) |
| Version: | 6.0 | OS: | Any |
| Assigned to: | Assigned Account | CPU Architecture: | Any |
[16 Jun 2008 10:12]
Jan Kneschke
This may be the same bug as Bug#37426
[19 Nov 2008 22:52]
Sveta Smirnova
Thank you for the report. I can not repeat described behavior with today main 6.0 and 6.0-rpl trees. Please indicate if you use another tree. Also please confirm results of select * from t1; should differ on master and slave after DELETE.
[11 Dec 2008 11:45]
Sveta Smirnova
I can not repeat neither crash, nor inconsistency between master and slave with current 6.0 tree. So close as "Can't repeat"
[28 Jan 2009 15:13]
Lars Thalmann
There is still a disabled test case in 6.0-rpl for this bug. Re-opening the bug.
[28 Jan 2009 20:31]
Mats Kindahl
Closing bug again since it is a duplicate of BUG#37426 and was fixed as part of that bug.
[28 Jan 2009 20: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/64393 2801 Mats Kindahl 2009-01-28 Bug #32462: Replication of CHAR(64) field with utf8 encoding crashes under RBR Enabling disabled test cases for this bug.
[30 Jan 2009 13:30]
Bugs System
Pushed into 6.0.10-alpha (revid:luis.soares@sun.com-20090129165607-wiskabxm948yx463) (version source revid:luis.soares@sun.com-20090129163120-e2ntks4wgpqde6zt) (merge vers: 6.0.10-alpha) (pib:6)

Description: When replicating a CHAR(64) field with UTF-8 encoding, the slave crashes because it cannot decode the field correctly. The error occurs after the introduction of 4-byte UTF-8 fields, but not before. The crash occurs because the length of the field cannot be decoded correctly. It seems to occur for any form of Field_string field, i.e., also for BLOB, TEXT, etc. The binary collation of the 'word' field below is possibly not necessary. How to repeat: source include/master-slave.inc; connection master; utf8_bin) default charset=utf8; create table t1 (word char(64) collate utf8_bin) default charset=utf8; insert into t1 values('foo'),('is'),('a'),('bar'); select * from t1; sync_slave_with_master; select * from t1; connection master; delete from t1 where word = _binary'foo'; select * from t1; sync_slave_with_master; select * from t1; connection master; drop table t1; sync_slave_with_master; Suggested fix: Ensure that the field can be decoded correctly even in the presence of 4-byte UTF-8 encodings.