2005-12-22 06:39:02 +01:00
stop slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
reset master;
reset slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
start slave;
CREATE TABLE t1 (C1 CHAR(1), C2 CHAR(1), INDEX (C1)) ENGINE = 'MYISAM' ;
SELECT * FROM t1;
C1 C2
SELECT * FROM t1;
C1 C2
INSERT INTO t1 VALUES ('A','B'), ('X','Y'), ('X','X');
INSERT INTO t1 VALUES ('A','C'), ('X','Z'), ('A','A');
SELECT * FROM t1 ORDER BY C1,C2;
C1 C2
A A
A B
A C
X X
X Y
X Z
SELECT * FROM t1 ORDER BY C1,C2;
C1 C2
A A
A B
A C
X X
X Y
X Z
DELETE FROM t1 WHERE C1 = C2;
SELECT * FROM t1 ORDER BY C1,C2;
C1 C2
A B
A C
X Y
X Z
SELECT * FROM t1 ORDER BY C1,C2;
C1 C2
A B
A C
X Y
X Z
UPDATE t1 SET C2 = 'I' WHERE C1 = 'A' AND C2 = 'C';
SELECT * FROM t1 ORDER BY C1,C2;
C1 C2
A B
A I
X Y
X Z
SELECT * FROM t1 ORDER BY C1,C2;
C1 C2
A B
A I
X Y
X Z
UPDATE t1 SET c2 = 'Q' WHERE c1 = 'A' AND c2 = 'N';
SELECT * FROM t1 ORDER BY c1,c2;
C1 C2
A B
A I
X Y
X Z
SELECT * FROM t1 ORDER BY c1,c2;
C1 C2
A B
A I
X Y
X Z
CREATE TABLE t2 (c1 INT, c12 char(1), c2 INT, PRIMARY KEY (c1)) ENGINE = 'MYISAM' ;
INSERT INTO t2
VALUES (1,'A',2), (2,'A',4), (3,'A',9), (4,'A',15), (5,'A',25),
(6,'A',35), (7,'A',50), (8,'A',64), (9,'A',81);
SELECT * FROM t2 ORDER BY c1,c2;
c1 c12 c2
1 A 2
2 A 4
3 A 9
4 A 15
5 A 25
6 A 35
7 A 50
8 A 64
9 A 81
SELECT * FROM t2 WHERE c2 = c1 * c1 ORDER BY c1,c2;
c1 c12 c2
2 A 4
3 A 9
5 A 25
8 A 64
9 A 81
SELECT * FROM t2 ORDER BY c1,c2;
c1 c12 c2
1 A 2
2 A 4
3 A 9
4 A 15
5 A 25
6 A 35
7 A 50
8 A 64
9 A 81
SELECT * FROM t2 WHERE c2 = c1 * c1 ORDER BY c1,c2;
c1 c12 c2
2 A 4
3 A 9
5 A 25
8 A 64
9 A 81
UPDATE t2 SET c2 = c1*c1 WHERE c2 != c1*c1;
SELECT * FROM t2 WHERE c2 = c1 * c1 ORDER BY c1,c2;
c1 c12 c2
1 A 1
2 A 4
3 A 9
4 A 16
5 A 25
6 A 36
7 A 49
8 A 64
9 A 81
SELECT * FROM t2 WHERE c2 = c1 * c1 ORDER BY c1,c2;
c1 c12 c2
1 A 1
2 A 4
3 A 9
4 A 16
5 A 25
6 A 36
7 A 49
8 A 64
9 A 81
UPDATE t2 SET c12 = 'Q' WHERE c1 = 1 AND c2 = 999;
SELECT * FROM t2 ORDER BY c1,c2;
c1 c12 c2
1 A 1
2 A 4
3 A 9
4 A 16
5 A 25
6 A 36
7 A 49
8 A 64
9 A 81
SELECT * FROM t2 ORDER BY c1,c2;
c1 c12 c2
1 A 1
2 A 4
3 A 9
4 A 16
5 A 25
6 A 36
7 A 49
8 A 64
9 A 81
DELETE FROM t2 WHERE c1 % 4 = 0;
SELECT * FROM t2 ORDER BY c1,c2;
c1 c12 c2
1 A 1
2 A 4
3 A 9
5 A 25
6 A 36
7 A 49
9 A 81
SELECT * FROM t2 ORDER BY c1,c2;
c1 c12 c2
1 A 1
2 A 4
3 A 9
5 A 25
6 A 36
7 A 49
9 A 81
UPDATE t2 SET c12='X';
CREATE TABLE t3 (C1 CHAR(1), C2 CHAR(1), pk1 INT, C3 CHAR(1), pk2 INT, PRIMARY KEY (pk1,pk2)) ENGINE = 'MYISAM' ;
INSERT INTO t3 VALUES ('A','B',1,'B',1), ('X','Y',2,'B',1), ('X','X',3,'B',1);
INSERT INTO t3 VALUES ('A','C',1,'B',2), ('X','Z',2,'B',2), ('A','A',3,'B',2);
SELECT * FROM t3 ORDER BY C1,C2;
C1 C2 pk1 C3 pk2
A A 3 B 2
A B 1 B 1
A C 1 B 2
X X 3 B 1
X Y 2 B 1
X Z 2 B 2
SELECT * FROM t3 ORDER BY C1,C2;
C1 C2 pk1 C3 pk2
A A 3 B 2
A B 1 B 1
A C 1 B 2
X X 3 B 1
X Y 2 B 1
X Z 2 B 2
DELETE FROM t3 WHERE C1 = C2;
SELECT * FROM t3 ORDER BY C1,C2;
C1 C2 pk1 C3 pk2
A B 1 B 1
A C 1 B 2
X Y 2 B 1
X Z 2 B 2
SELECT * FROM t3 ORDER BY C1,C2;
C1 C2 pk1 C3 pk2
A B 1 B 1
A C 1 B 2
X Y 2 B 1
X Z 2 B 2
UPDATE t3 SET C2 = 'I' WHERE C1 = 'A' AND C2 = 'C';
SELECT * FROM t3 ORDER BY C1,C2;
C1 C2 pk1 C3 pk2
A B 1 B 1
A I 1 B 2
X Y 2 B 1
X Z 2 B 2
SELECT * FROM t3 ORDER BY C1,C2;
C1 C2 pk1 C3 pk2
A B 1 B 1
A I 1 B 2
X Y 2 B 1
X Z 2 B 2
CREATE TABLE t6 (C1 CHAR(1), C2 CHAR(1), C3 INT) ENGINE = 'MYISAM' ;
INSERT INTO t6 VALUES ('A','B',1), ('X','Y',2), ('X','X',3);
INSERT INTO t6 VALUES ('A','C',4), ('X','Z',5), ('A','A',6);
SELECT * FROM t6 ORDER BY C3;
C1 C2 C3
A B 1
X Y 2
X X 3
A C 4
X Z 5
A A 6
SELECT * FROM t6 ORDER BY C3;
C1 C2 C3
A B 1
X Y 2
X X 3
A C 4
X Z 5
A A 6
DELETE FROM t6 WHERE C1 = C2;
SELECT * FROM t6 ORDER BY C3;
C1 C2 C3
A B 1
X Y 2
A C 4
X Z 5
SELECT * FROM t6 ORDER BY C3;
C1 C2 C3
A B 1
X Y 2
A C 4
X Z 5
UPDATE t6 SET C2 = 'I' WHERE C1 = 'A' AND C2 = 'C';
SELECT * FROM t6 ORDER BY C3;
C1 C2 C3
A B 1
X Y 2
A I 4
X Z 5
SELECT * FROM t6 ORDER BY C3;
C1 C2 C3
A B 1
X Y 2
A I 4
X Z 5
CREATE TABLE t5 (C1 CHAR(1), C2 CHAR(1), C3 INT PRIMARY KEY) ENGINE = 'MYISAM' ;
INSERT INTO t5 VALUES ('A','B',1), ('X','Y',2), ('X','X',3);
INSERT INTO t5 VALUES ('A','C',4), ('X','Z',5), ('A','A',6);
UPDATE t5,t2,t3 SET t5.C2='Q', t2.c12='R', t3.C3 ='S' WHERE t5.C1 = t2.c12 AND t5.C1 = t3.C1;
SELECT * FROM t5,t2,t3 WHERE t5.C2='Q' AND t2.c12='R' AND t3.C3 ='S' ORDER BY t5.C3,t2.c1,t3.pk1,t3.pk2;
C1 C2 C3 c1 c12 c2 C1 C2 pk1 C3 pk2
X Q 2 1 R 1 X Y 2 S 1
X Q 2 1 R 1 X Z 2 S 2
X Q 2 2 R 4 X Y 2 S 1
X Q 2 2 R 4 X Z 2 S 2
X Q 2 3 R 9 X Y 2 S 1
X Q 2 3 R 9 X Z 2 S 2
X Q 2 5 R 25 X Y 2 S 1
X Q 2 5 R 25 X Z 2 S 2
X Q 2 6 R 36 X Y 2 S 1
X Q 2 6 R 36 X Z 2 S 2
X Q 2 7 R 49 X Y 2 S 1
X Q 2 7 R 49 X Z 2 S 2
X Q 2 9 R 81 X Y 2 S 1
X Q 2 9 R 81 X Z 2 S 2
X Q 3 1 R 1 X Y 2 S 1
X Q 3 1 R 1 X Z 2 S 2
X Q 3 2 R 4 X Y 2 S 1
X Q 3 2 R 4 X Z 2 S 2
X Q 3 3 R 9 X Y 2 S 1
X Q 3 3 R 9 X Z 2 S 2
X Q 3 5 R 25 X Y 2 S 1
X Q 3 5 R 25 X Z 2 S 2
X Q 3 6 R 36 X Y 2 S 1
X Q 3 6 R 36 X Z 2 S 2
X Q 3 7 R 49 X Y 2 S 1
X Q 3 7 R 49 X Z 2 S 2
X Q 3 9 R 81 X Y 2 S 1
X Q 3 9 R 81 X Z 2 S 2
X Q 5 1 R 1 X Y 2 S 1
X Q 5 1 R 1 X Z 2 S 2
X Q 5 2 R 4 X Y 2 S 1
X Q 5 2 R 4 X Z 2 S 2
X Q 5 3 R 9 X Y 2 S 1
X Q 5 3 R 9 X Z 2 S 2
X Q 5 5 R 25 X Y 2 S 1
X Q 5 5 R 25 X Z 2 S 2
X Q 5 6 R 36 X Y 2 S 1
X Q 5 6 R 36 X Z 2 S 2
X Q 5 7 R 49 X Y 2 S 1
X Q 5 7 R 49 X Z 2 S 2
X Q 5 9 R 81 X Y 2 S 1
X Q 5 9 R 81 X Z 2 S 2
SELECT * FROM t5,t2,t3 WHERE t5.C2='Q' AND t2.c12='R' AND t3.C3 ='S' ORDER BY t5.C3,t2.c1,t3.pk1,t3.pk2;
C1 C2 C3 c1 c12 c2 C1 C2 pk1 C3 pk2
X Q 2 1 R 1 X Y 2 S 1
X Q 2 1 R 1 X Z 2 S 2
X Q 2 2 R 4 X Y 2 S 1
X Q 2 2 R 4 X Z 2 S 2
X Q 2 3 R 9 X Y 2 S 1
X Q 2 3 R 9 X Z 2 S 2
X Q 2 5 R 25 X Y 2 S 1
X Q 2 5 R 25 X Z 2 S 2
X Q 2 6 R 36 X Y 2 S 1
X Q 2 6 R 36 X Z 2 S 2
X Q 2 7 R 49 X Y 2 S 1
X Q 2 7 R 49 X Z 2 S 2
X Q 2 9 R 81 X Y 2 S 1
X Q 2 9 R 81 X Z 2 S 2
X Q 3 1 R 1 X Y 2 S 1
X Q 3 1 R 1 X Z 2 S 2
X Q 3 2 R 4 X Y 2 S 1
X Q 3 2 R 4 X Z 2 S 2
X Q 3 3 R 9 X Y 2 S 1
X Q 3 3 R 9 X Z 2 S 2
X Q 3 5 R 25 X Y 2 S 1
X Q 3 5 R 25 X Z 2 S 2
X Q 3 6 R 36 X Y 2 S 1
X Q 3 6 R 36 X Z 2 S 2
X Q 3 7 R 49 X Y 2 S 1
X Q 3 7 R 49 X Z 2 S 2
X Q 3 9 R 81 X Y 2 S 1
X Q 3 9 R 81 X Z 2 S 2
X Q 5 1 R 1 X Y 2 S 1
X Q 5 1 R 1 X Z 2 S 2
X Q 5 2 R 4 X Y 2 S 1
X Q 5 2 R 4 X Z 2 S 2
X Q 5 3 R 9 X Y 2 S 1
X Q 5 3 R 9 X Z 2 S 2
X Q 5 5 R 25 X Y 2 S 1
X Q 5 5 R 25 X Z 2 S 2
X Q 5 6 R 36 X Y 2 S 1
X Q 5 6 R 36 X Z 2 S 2
X Q 5 7 R 49 X Y 2 S 1
X Q 5 7 R 49 X Z 2 S 2
X Q 5 9 R 81 X Y 2 S 1
X Q 5 9 R 81 X Z 2 S 2
CREATE TABLE t4 (C1 CHAR(1) PRIMARY KEY, B1 BIT(1), B2 BIT(1) NOT NULL DEFAULT 0, C2 CHAR(1) NOT NULL DEFAULT 'A') ENGINE = 'MYISAM' ;
INSERT INTO t4 SET C1 = 1;
SELECT C1,HEX(B1),HEX(B2) FROM t4 ORDER BY C1;
C1 HEX(B1) HEX(B2)
1 NULL 0
SELECT C1,HEX(B1),HEX(B2) FROM t4 ORDER BY C1;
C1 HEX(B1) HEX(B2)
1 NULL 0
CREATE TABLE t7 (C1 INT PRIMARY KEY, C2 INT) ENGINE = 'MYISAM' ;
--- on slave: original values ---
INSERT INTO t7 VALUES (1,3), (2,6), (3,9);
SELECT * FROM t7 ORDER BY C1;
C1 C2
1 3
2 6
3 9
2007-12-12 12:14:59 +02:00
set @@global.slave_exec_mode= 'IDEMPOTENT';
2005-12-22 06:39:02 +01:00
--- on master: new values inserted ---
INSERT INTO t7 VALUES (1,2), (2,4), (3,6);
SELECT * FROM t7 ORDER BY C1;
C1 C2
1 2
2 4
3 6
2007-12-12 12:14:59 +02:00
set @@global.slave_exec_mode= default;
2005-12-22 06:39:02 +01:00
--- on slave: old values should be overwritten by replicated values ---
SELECT * FROM t7 ORDER BY C1;
C1 C2
1 2
2 4
3 6
--- on master ---
2006-02-24 16:19:55 +01:00
CREATE TABLE t8 (a INT PRIMARY KEY, b INT UNIQUE, c INT UNIQUE) ENGINE = 'MYISAM' ;
INSERT INTO t8 VALUES (99,99,99);
INSERT INTO t8 VALUES (99,22,33);
ERROR 23000: Duplicate entry '99' for key 'PRIMARY'
INSERT INTO t8 VALUES (11,99,33);
ERROR 23000: Duplicate entry '99' for key 'b'
INSERT INTO t8 VALUES (11,22,99);
ERROR 23000: Duplicate entry '99' for key 'c'
SELECT * FROM t8 ORDER BY a;
2005-12-22 06:39:02 +01:00
a b c
99 99 99
--- on slave ---
2006-02-24 16:19:55 +01:00
SELECT * FROM t8 ORDER BY a;
2005-12-22 06:39:02 +01:00
a b c
99 99 99
2006-02-24 16:19:55 +01:00
INSERT INTO t8 VALUES (1,2,3), (2,4,6), (3,6,9);
SELECT * FROM t8 ORDER BY a;
2005-12-22 06:39:02 +01:00
a b c
1 2 3
2 4 6
3 6 9
99 99 99
2007-12-12 12:14:59 +02:00
set @@global.slave_exec_mode= 'IDEMPOTENT';
2005-12-22 06:39:02 +01:00
--- on master ---
2006-02-24 16:19:55 +01:00
INSERT INTO t8 VALUES (2,4,8);
2007-12-12 12:14:59 +02:00
set @@global.slave_exec_mode= default;
2005-12-22 06:39:02 +01:00
--- on slave ---
2006-02-24 16:19:55 +01:00
SELECT * FROM t8 ORDER BY a;
2005-12-22 06:39:02 +01:00
a b c
1 2 3
2 4 8
3 6 9
99 99 99
2007-11-09 11:02:51 +01:00
**** Test for BUG#31552 ****
**** On Master ****
DELETE FROM t1;
**** Resetting master and slave ****
2008-07-10 18:09:39 +02:00
include/stop_slave.inc
2007-11-09 11:02:51 +01:00
RESET SLAVE;
RESET MASTER;
2008-07-10 18:09:39 +02:00
include/start_slave.inc
2007-11-09 11:02:51 +01:00
**** On Master ****
INSERT INTO t1 VALUES ('K','K'), ('L','L'), ('M','M');
**** On Master ****
2007-12-12 20:12:29 +01:00
set @@global.slave_exec_mode= 'IDEMPOTENT';
2007-11-09 11:02:51 +01:00
DELETE FROM t1 WHERE C1 = 'L';
DELETE FROM t1;
SELECT COUNT(*) FROM t1 ORDER BY c1,c2;
COUNT(*) 0
2007-12-12 20:12:29 +01:00
set @@global.slave_exec_mode= default;
2007-11-09 11:02:51 +01:00
Last_SQL_Error
BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.
Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).
Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.
2008-06-30 22:11:18 +02:00
2007-11-09 11:02:51 +01:00
SELECT COUNT(*) FROM t1 ORDER BY c1,c2;
COUNT(*) 0
2008-06-19 18:02:04 +05:00
**** Test for BUG#37076 ****
**** On Master ****
DROP TABLE IF EXISTS t1;
CREATE TABLE t1 (a TIMESTAMP, b DATETIME, c DATE);
INSERT INTO t1 VALUES(
'2005-11-14 01:01:01', '2005-11-14 01:01:02', '2005-11-14');
**** On Slave ****
SELECT * FROM t1;
a b c
2005-11-14 01:01:01 2005-11-14 01:01:02 2005-11-14
2006-02-24 16:19:55 +01:00
DROP TABLE IF EXISTS t1,t2,t3,t4,t5,t6,t7,t8;
BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.
Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).
Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.
2008-06-30 22:11:18 +02:00
CREATE TABLE t1 (i INT NOT NULL,
c CHAR(16) CHARACTER SET utf8 NOT NULL,
2008-08-12 17:09:36 +08:00
j INT NOT NULL) ENGINE = 'MYISAM' ;
BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.
Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).
Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.
2008-06-30 22:11:18 +02:00
CREATE TABLE t2 (i INT NOT NULL,
c CHAR(16) CHARACTER SET utf8 NOT NULL,
2008-08-12 17:09:36 +08:00
j INT NOT NULL) ENGINE = 'MYISAM' ;
BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.
Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).
Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.
2008-06-30 22:11:18 +02:00
ALTER TABLE t2 MODIFY c CHAR(128) CHARACTER SET utf8 NOT NULL;
CREATE TABLE t3 (i INT NOT NULL,
c CHAR(128) CHARACTER SET utf8 NOT NULL,
2008-08-12 17:09:36 +08:00
j INT NOT NULL) ENGINE = 'MYISAM' ;
BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.
Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).
Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.
2008-06-30 22:11:18 +02:00
ALTER TABLE t3 MODIFY c CHAR(16) CHARACTER SET utf8 NOT NULL;
CREATE TABLE t4 (i INT NOT NULL,
c CHAR(128) CHARACTER SET utf8 NOT NULL,
2008-08-12 17:09:36 +08:00
j INT NOT NULL) ENGINE = 'MYISAM' ;
BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.
Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).
Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.
2008-06-30 22:11:18 +02:00
CREATE TABLE t5 (i INT NOT NULL,
c CHAR(255) CHARACTER SET utf8 NOT NULL,
2008-08-12 17:09:36 +08:00
j INT NOT NULL) ENGINE = 'MYISAM' ;
BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.
Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).
Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.
2008-06-30 22:11:18 +02:00
ALTER TABLE t5 MODIFY c CHAR(16) CHARACTER SET utf8 NOT NULL;
CREATE TABLE t6 (i INT NOT NULL,
c CHAR(255) CHARACTER SET utf8 NOT NULL,
2008-08-12 17:09:36 +08:00
j INT NOT NULL) ENGINE = 'MYISAM' ;
BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.
Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).
Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.
2008-06-30 22:11:18 +02:00
ALTER TABLE t6 MODIFY c CHAR(128) CHARACTER SET utf8 NOT NULL;
CREATE TABLE t7 (i INT NOT NULL,
c CHAR(255) CHARACTER SET utf8 NOT NULL,
2008-08-12 17:09:36 +08:00
j INT NOT NULL) ENGINE = 'MYISAM' ;
BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.
Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).
Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.
2008-06-30 22:11:18 +02:00
[expecting slave to replicate correctly]
INSERT INTO t1 VALUES (1, "", 1);
INSERT INTO t1 VALUES (2, repeat(_utf8'a', 16), 2);
Comparing tables master:test.t1 and slave:test.t1
[expecting slave to replicate correctly]
INSERT INTO t2 VALUES (1, "", 1);
INSERT INTO t2 VALUES (2, repeat(_utf8'a', 16), 2);
Comparing tables master:test.t2 and slave:test.t2
[expecting slave to stop]
INSERT INTO t3 VALUES (1, "", 1);
INSERT INTO t3 VALUES (2, repeat(_utf8'a', 128), 2);
Last_SQL_Error
Table definition on master and slave does not match: Column 1 size mismatch - master has size 384, test.t3 on slave has size 49. Master's column size should be <= the slave's column size.
2008-08-12 17:09:36 +08:00
RESET MASTER;
STOP SLAVE;
RESET SLAVE;
BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.
Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).
Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.
2008-06-30 22:11:18 +02:00
START SLAVE;
[expecting slave to replicate correctly]
INSERT INTO t4 VALUES (1, "", 1);
INSERT INTO t4 VALUES (2, repeat(_utf8'a', 128), 2);
Comparing tables master:test.t4 and slave:test.t4
[expecting slave to stop]
INSERT INTO t5 VALUES (1, "", 1);
INSERT INTO t5 VALUES (2, repeat(_utf8'a', 255), 2);
Last_SQL_Error
Table definition on master and slave does not match: Column 1 size mismatch - master has size 765, test.t5 on slave has size 49. Master's column size should be <= the slave's column size.
2008-08-12 17:09:36 +08:00
RESET MASTER;
STOP SLAVE;
RESET SLAVE;
BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.
Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).
Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.
2008-06-30 22:11:18 +02:00
START SLAVE;
[expecting slave to stop]
INSERT INTO t6 VALUES (1, "", 1);
INSERT INTO t6 VALUES (2, repeat(_utf8'a', 255), 2);
Last_SQL_Error
Table definition on master and slave does not match: Column 1 size mismatch - master has size 765, test.t6 on slave has size 385. Master's column size should be <= the slave's column size.
2008-08-12 17:09:36 +08:00
RESET MASTER;
STOP SLAVE;
RESET SLAVE;
BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.
Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).
Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.
2008-06-30 22:11:18 +02:00
START SLAVE;
[expecting slave to replicate correctly]
INSERT INTO t7 VALUES (1, "", 1);
INSERT INTO t7 VALUES (2, repeat(_utf8'a', 255), 2);
Comparing tables master:test.t7 and slave:test.t7
drop table t1, t2, t3, t4, t5, t6, t7;
2008-09-03 22:04:07 +02:00
CREATE TABLE t1 (a INT PRIMARY KEY) ENGINE='MYISAM' ;
INSERT INTO t1 VALUES (1), (2), (3);
UPDATE t1 SET a = 10;
ERROR 23000: Duplicate entry '10' for key 'PRIMARY'
INSERT INTO t1 VALUES (4);
Comparing tables master:test.t1 and slave:test.t1
drop table t1;
