BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#43789 to mysql-5.1-bugteam
The replication was generating corrupted data, warning messages on Valgrind
and aborting on debug mode while replicating a "null" to "not null" field.
Specifically the unpack_row routine, was considering the slave's table
definition and trying to retrieve a field value, where there was nothing to be
retrieved, ignoring the fact that the value was defined as "null" by the master.
To fix the problem, we proceed as follows:
1 - If it is not STRICT sql_mode, implicit default values are used, regardless
if it is multi-row or single-row statement.
2 - However, if it is STRICT mode, then a we do what follows:
2.1 If it is a transactional engine, we do a rollback on the first NULL that is
to be set into a NOT NULL column and return an error.
2.2 If it is a non-transactional engine and it is the first row to be inserted
with multi-row, we also return the error. Otherwise, we proceed with the
execution, use implicit default values and print out warning messages.
Unfortunately, the current patch cannot mimic the behavior showed by the master
for updates on multi-tables and multi-row inserts. This happens because such
statements are unfolded in different row events. For instance, considering the
following updates and strict mode:
(master)
create table t1 (a int);
create table t2 (a int not null);
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
t1 would have (10) and t2 would have (0) as this would be handled as a
multi-row update. On the other hand, if we had the following updates:
(master)
create table t1 (a int);
create table t2 (a int);
(slave)
create table t1 (a int);
create table t2 (a int not null);
(master)
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
On the master t1 would have (10) and t2 would have (NULL). On
the slave, t1 would have (10) but the update on t1 would fail.
2009-10-22 01:15:45 +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;
|
|
|
|
|
SET SQL_LOG_BIN= 0;
|
|
|
|
|
CREATE TABLE t1(`a` INT, `b` DATE DEFAULT NULL,
|
|
|
|
|
`c` INT DEFAULT NULL,
|
|
|
|
|
PRIMARY KEY(`a`)) ENGINE=MyISAM DEFAULT CHARSET=LATIN1;
|
|
|
|
|
CREATE TABLE t2(`a` INT, `b` DATE DEFAULT NULL,
|
|
|
|
|
PRIMARY KEY(`a`)) ENGINE=MyISAM DEFAULT CHARSET=LATIN1;
|
|
|
|
|
CREATE TABLE t3(`a` INT, `b` DATE DEFAULT NULL,
|
|
|
|
|
PRIMARY KEY(`a`)) ENGINE=MyISAM DEFAULT CHARSET=LATIN1;
|
|
|
|
|
CREATE TABLE t4(`a` INT, `b` DATE DEFAULT NULL,
|
|
|
|
|
`c` INT DEFAULT NULL,
|
|
|
|
|
PRIMARY KEY(`a`)) ENGINE=MyISAM DEFAULT CHARSET=LATIN1;
|
|
|
|
|
SET SQL_LOG_BIN= 1;
|
|
|
|
|
CREATE TABLE t1(`a` INT, `b` DATE DEFAULT NULL,
|
|
|
|
|
`c` INT DEFAULT NULL,
|
|
|
|
|
PRIMARY KEY(`a`)) ENGINE=MyISAM DEFAULT CHARSET=LATIN1;
|
|
|
|
|
CREATE TABLE t2(`a` INT, `b` DATE DEFAULT NULL,
|
|
|
|
|
PRIMARY KEY(`a`)) ENGINE=MyISAM DEFAULT CHARSET=LATIN1;
|
|
|
|
|
CREATE TABLE t3(`a` INT, `b` DATE DEFAULT '0000-00-00',
|
|
|
|
|
`c` INT DEFAULT 500,
|
|
|
|
|
PRIMARY KEY(`a`)) ENGINE=MyISAM DEFAULT CHARSET=LATIN1;
|
|
|
|
|
CREATE TABLE t4(`a` INT, `b` DATE DEFAULT '0000-00-00',
|
|
|
|
|
PRIMARY KEY(`a`)) ENGINE=MyISAM DEFAULT CHARSET=LATIN1;
|
|
|
|
|
************* EXECUTION WITH INSERTS *************
|
|
|
|
|
INSERT INTO t1(a,b,c) VALUES (1, null, 1);
|
|
|
|
|
INSERT INTO t1(a,b,c) VALUES (2,'1111-11-11', 2);
|
|
|
|
|
INSERT INTO t1(a,b) VALUES (3, null);
|
|
|
|
|
INSERT INTO t1(a,c) VALUES (4, 4);
|
|
|
|
|
INSERT INTO t1(a) VALUES (5);
|
|
|
|
|
INSERT INTO t2(a,b) VALUES (1, null);
|
|
|
|
|
INSERT INTO t2(a,b) VALUES (2,'1111-11-11');
|
|
|
|
|
INSERT INTO t2(a) VALUES (3);
|
|
|
|
|
INSERT INTO t3(a,b) VALUES (1, null);
|
|
|
|
|
INSERT INTO t3(a,b) VALUES (2,'1111-11-11');
|
|
|
|
|
INSERT INTO t3(a) VALUES (3);
|
|
|
|
|
INSERT INTO t4(a,b,c) VALUES (1, null, 1);
|
|
|
|
|
INSERT INTO t4(a,b,c) VALUES (2,'1111-11-11', 2);
|
|
|
|
|
INSERT INTO t4(a,b) VALUES (3, null);
|
|
|
|
|
INSERT INTO t4(a,c) VALUES (4, 4);
|
|
|
|
|
INSERT INTO t4(a) VALUES (5);
|
|
|
|
|
************* SHOWING THE RESULT SETS WITH INSERTS *************
|
|
|
|
|
TABLES t1 and t2 must be equal otherwise an error will be thrown.
|
|
|
|
|
Comparing tables master:test.t1 and slave:test.t1
|
|
|
|
|
Comparing tables master:test.t2 and slave:test.t2
|
|
|
|
|
TABLES t2 and t3 must be different.
|
2009-10-22 01:19:52 +01:00
|
|
|
SELECT * FROM t3 ORDER BY a;
|
BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#43789 to mysql-5.1-bugteam
The replication was generating corrupted data, warning messages on Valgrind
and aborting on debug mode while replicating a "null" to "not null" field.
Specifically the unpack_row routine, was considering the slave's table
definition and trying to retrieve a field value, where there was nothing to be
retrieved, ignoring the fact that the value was defined as "null" by the master.
To fix the problem, we proceed as follows:
1 - If it is not STRICT sql_mode, implicit default values are used, regardless
if it is multi-row or single-row statement.
2 - However, if it is STRICT mode, then a we do what follows:
2.1 If it is a transactional engine, we do a rollback on the first NULL that is
to be set into a NOT NULL column and return an error.
2.2 If it is a non-transactional engine and it is the first row to be inserted
with multi-row, we also return the error. Otherwise, we proceed with the
execution, use implicit default values and print out warning messages.
Unfortunately, the current patch cannot mimic the behavior showed by the master
for updates on multi-tables and multi-row inserts. This happens because such
statements are unfolded in different row events. For instance, considering the
following updates and strict mode:
(master)
create table t1 (a int);
create table t2 (a int not null);
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
t1 would have (10) and t2 would have (0) as this would be handled as a
multi-row update. On the other hand, if we had the following updates:
(master)
create table t1 (a int);
create table t2 (a int);
(slave)
create table t1 (a int);
create table t2 (a int not null);
(master)
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
On the master t1 would have (10) and t2 would have (NULL). On
the slave, t1 would have (10) but the update on t1 would fail.
2009-10-22 01:15:45 +01:00
|
|
|
a b
|
|
|
|
|
1 NULL
|
|
|
|
|
2 1111-11-11
|
|
|
|
|
3 NULL
|
2009-10-22 01:19:52 +01:00
|
|
|
SELECT * FROM t3 ORDER BY a;
|
BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#43789 to mysql-5.1-bugteam
The replication was generating corrupted data, warning messages on Valgrind
and aborting on debug mode while replicating a "null" to "not null" field.
Specifically the unpack_row routine, was considering the slave's table
definition and trying to retrieve a field value, where there was nothing to be
retrieved, ignoring the fact that the value was defined as "null" by the master.
To fix the problem, we proceed as follows:
1 - If it is not STRICT sql_mode, implicit default values are used, regardless
if it is multi-row or single-row statement.
2 - However, if it is STRICT mode, then a we do what follows:
2.1 If it is a transactional engine, we do a rollback on the first NULL that is
to be set into a NOT NULL column and return an error.
2.2 If it is a non-transactional engine and it is the first row to be inserted
with multi-row, we also return the error. Otherwise, we proceed with the
execution, use implicit default values and print out warning messages.
Unfortunately, the current patch cannot mimic the behavior showed by the master
for updates on multi-tables and multi-row inserts. This happens because such
statements are unfolded in different row events. For instance, considering the
following updates and strict mode:
(master)
create table t1 (a int);
create table t2 (a int not null);
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
t1 would have (10) and t2 would have (0) as this would be handled as a
multi-row update. On the other hand, if we had the following updates:
(master)
create table t1 (a int);
create table t2 (a int);
(slave)
create table t1 (a int);
create table t2 (a int not null);
(master)
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
On the master t1 would have (10) and t2 would have (NULL). On
the slave, t1 would have (10) but the update on t1 would fail.
2009-10-22 01:15:45 +01:00
|
|
|
a b c
|
|
|
|
|
1 NULL 500
|
|
|
|
|
2 1111-11-11 500
|
|
|
|
|
3 NULL 500
|
2009-10-22 01:19:52 +01:00
|
|
|
SELECT * FROM t4 ORDER BY a;
|
BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#43789 to mysql-5.1-bugteam
The replication was generating corrupted data, warning messages on Valgrind
and aborting on debug mode while replicating a "null" to "not null" field.
Specifically the unpack_row routine, was considering the slave's table
definition and trying to retrieve a field value, where there was nothing to be
retrieved, ignoring the fact that the value was defined as "null" by the master.
To fix the problem, we proceed as follows:
1 - If it is not STRICT sql_mode, implicit default values are used, regardless
if it is multi-row or single-row statement.
2 - However, if it is STRICT mode, then a we do what follows:
2.1 If it is a transactional engine, we do a rollback on the first NULL that is
to be set into a NOT NULL column and return an error.
2.2 If it is a non-transactional engine and it is the first row to be inserted
with multi-row, we also return the error. Otherwise, we proceed with the
execution, use implicit default values and print out warning messages.
Unfortunately, the current patch cannot mimic the behavior showed by the master
for updates on multi-tables and multi-row inserts. This happens because such
statements are unfolded in different row events. For instance, considering the
following updates and strict mode:
(master)
create table t1 (a int);
create table t2 (a int not null);
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
t1 would have (10) and t2 would have (0) as this would be handled as a
multi-row update. On the other hand, if we had the following updates:
(master)
create table t1 (a int);
create table t2 (a int);
(slave)
create table t1 (a int);
create table t2 (a int not null);
(master)
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
On the master t1 would have (10) and t2 would have (NULL). On
the slave, t1 would have (10) but the update on t1 would fail.
2009-10-22 01:15:45 +01:00
|
|
|
a b c
|
|
|
|
|
1 NULL 1
|
|
|
|
|
2 1111-11-11 2
|
|
|
|
|
3 NULL NULL
|
|
|
|
|
4 NULL 4
|
|
|
|
|
5 NULL NULL
|
2009-10-22 01:19:52 +01:00
|
|
|
SELECT * FROM t4 ORDER BY a;
|
BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#43789 to mysql-5.1-bugteam
The replication was generating corrupted data, warning messages on Valgrind
and aborting on debug mode while replicating a "null" to "not null" field.
Specifically the unpack_row routine, was considering the slave's table
definition and trying to retrieve a field value, where there was nothing to be
retrieved, ignoring the fact that the value was defined as "null" by the master.
To fix the problem, we proceed as follows:
1 - If it is not STRICT sql_mode, implicit default values are used, regardless
if it is multi-row or single-row statement.
2 - However, if it is STRICT mode, then a we do what follows:
2.1 If it is a transactional engine, we do a rollback on the first NULL that is
to be set into a NOT NULL column and return an error.
2.2 If it is a non-transactional engine and it is the first row to be inserted
with multi-row, we also return the error. Otherwise, we proceed with the
execution, use implicit default values and print out warning messages.
Unfortunately, the current patch cannot mimic the behavior showed by the master
for updates on multi-tables and multi-row inserts. This happens because such
statements are unfolded in different row events. For instance, considering the
following updates and strict mode:
(master)
create table t1 (a int);
create table t2 (a int not null);
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
t1 would have (10) and t2 would have (0) as this would be handled as a
multi-row update. On the other hand, if we had the following updates:
(master)
create table t1 (a int);
create table t2 (a int);
(slave)
create table t1 (a int);
create table t2 (a int not null);
(master)
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
On the master t1 would have (10) and t2 would have (NULL). On
the slave, t1 would have (10) but the update on t1 would fail.
2009-10-22 01:15:45 +01:00
|
|
|
a b
|
|
|
|
|
1 NULL
|
|
|
|
|
2 1111-11-11
|
|
|
|
|
3 NULL
|
|
|
|
|
4 NULL
|
|
|
|
|
5 NULL
|
|
|
|
|
************* EXECUTION WITH UPDATES and REPLACES *************
|
|
|
|
|
DELETE FROM t1;
|
|
|
|
|
INSERT INTO t1(a,b,c) VALUES (1,'1111-11-11', 1);
|
|
|
|
|
REPLACE INTO t1(a,b,c) VALUES (2,'1111-11-11', 2);
|
|
|
|
|
UPDATE t1 set b= NULL, c= 300 where a= 1;
|
|
|
|
|
REPLACE INTO t1(a,b,c) VALUES (2, NULL, 300);
|
|
|
|
|
************* SHOWING THE RESULT SETS WITH UPDATES and REPLACES *************
|
|
|
|
|
TABLES t1 and t2 must be equal otherwise an error will be thrown.
|
|
|
|
|
Comparing tables master:test.t1 and slave:test.t1
|
|
|
|
|
************* CLEANING *************
|
|
|
|
|
DROP TABLE t1;
|
|
|
|
|
DROP TABLE t2;
|
|
|
|
|
DROP TABLE t3;
|
|
|
|
|
DROP TABLE t4;
|
|
|
|
|
SET SQL_LOG_BIN= 0;
|
|
|
|
|
CREATE TABLE t1 (`a` INT, `b` BIT DEFAULT NULL, `c` BIT DEFAULT NULL,
|
|
|
|
|
PRIMARY KEY (`a`)) ENGINE= MyISAM;
|
|
|
|
|
SET SQL_LOG_BIN= 1;
|
|
|
|
|
CREATE TABLE t1 (`a` INT, `b` BIT DEFAULT b'01', `c` BIT DEFAULT NULL,
|
|
|
|
|
PRIMARY KEY (`a`)) ENGINE= MyISAM;
|
|
|
|
|
************* EXECUTION WITH INSERTS *************
|
|
|
|
|
INSERT INTO t1(a,b,c) VALUES (1, null, b'01');
|
|
|
|
|
INSERT INTO t1(a,b,c) VALUES (2,b'00', b'01');
|
|
|
|
|
INSERT INTO t1(a,b) VALUES (3, null);
|
|
|
|
|
INSERT INTO t1(a,c) VALUES (4, b'01');
|
|
|
|
|
INSERT INTO t1(a) VALUES (5);
|
|
|
|
|
************* SHOWING THE RESULT SETS WITH INSERTS *************
|
|
|
|
|
TABLES t1 and t2 must be different.
|
2009-10-22 01:19:52 +01:00
|
|
|
SELECT a,b+0,c+0 FROM t1 ORDER BY a;
|
BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#43789 to mysql-5.1-bugteam
The replication was generating corrupted data, warning messages on Valgrind
and aborting on debug mode while replicating a "null" to "not null" field.
Specifically the unpack_row routine, was considering the slave's table
definition and trying to retrieve a field value, where there was nothing to be
retrieved, ignoring the fact that the value was defined as "null" by the master.
To fix the problem, we proceed as follows:
1 - If it is not STRICT sql_mode, implicit default values are used, regardless
if it is multi-row or single-row statement.
2 - However, if it is STRICT mode, then a we do what follows:
2.1 If it is a transactional engine, we do a rollback on the first NULL that is
to be set into a NOT NULL column and return an error.
2.2 If it is a non-transactional engine and it is the first row to be inserted
with multi-row, we also return the error. Otherwise, we proceed with the
execution, use implicit default values and print out warning messages.
Unfortunately, the current patch cannot mimic the behavior showed by the master
for updates on multi-tables and multi-row inserts. This happens because such
statements are unfolded in different row events. For instance, considering the
following updates and strict mode:
(master)
create table t1 (a int);
create table t2 (a int not null);
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
t1 would have (10) and t2 would have (0) as this would be handled as a
multi-row update. On the other hand, if we had the following updates:
(master)
create table t1 (a int);
create table t2 (a int);
(slave)
create table t1 (a int);
create table t2 (a int not null);
(master)
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
On the master t1 would have (10) and t2 would have (NULL). On
the slave, t1 would have (10) but the update on t1 would fail.
2009-10-22 01:15:45 +01:00
|
|
|
a b+0 c+0
|
|
|
|
|
1 NULL 1
|
|
|
|
|
2 0 1
|
|
|
|
|
3 NULL NULL
|
|
|
|
|
4 NULL 1
|
|
|
|
|
5 NULL NULL
|
2009-10-22 01:19:52 +01:00
|
|
|
SELECT a,b+0,c+0 FROM t1 ORDER BY a;
|
BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#43789 to mysql-5.1-bugteam
The replication was generating corrupted data, warning messages on Valgrind
and aborting on debug mode while replicating a "null" to "not null" field.
Specifically the unpack_row routine, was considering the slave's table
definition and trying to retrieve a field value, where there was nothing to be
retrieved, ignoring the fact that the value was defined as "null" by the master.
To fix the problem, we proceed as follows:
1 - If it is not STRICT sql_mode, implicit default values are used, regardless
if it is multi-row or single-row statement.
2 - However, if it is STRICT mode, then a we do what follows:
2.1 If it is a transactional engine, we do a rollback on the first NULL that is
to be set into a NOT NULL column and return an error.
2.2 If it is a non-transactional engine and it is the first row to be inserted
with multi-row, we also return the error. Otherwise, we proceed with the
execution, use implicit default values and print out warning messages.
Unfortunately, the current patch cannot mimic the behavior showed by the master
for updates on multi-tables and multi-row inserts. This happens because such
statements are unfolded in different row events. For instance, considering the
following updates and strict mode:
(master)
create table t1 (a int);
create table t2 (a int not null);
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
t1 would have (10) and t2 would have (0) as this would be handled as a
multi-row update. On the other hand, if we had the following updates:
(master)
create table t1 (a int);
create table t2 (a int);
(slave)
create table t1 (a int);
create table t2 (a int not null);
(master)
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
On the master t1 would have (10) and t2 would have (NULL). On
the slave, t1 would have (10) but the update on t1 would fail.
2009-10-22 01:15:45 +01:00
|
|
|
a b+0 c+0
|
|
|
|
|
1 NULL 1
|
|
|
|
|
2 0 1
|
|
|
|
|
3 NULL NULL
|
|
|
|
|
4 NULL 1
|
|
|
|
|
5 NULL NULL
|
|
|
|
|
************* EXECUTION WITH UPDATES and REPLACES *************
|
|
|
|
|
DELETE FROM t1;
|
|
|
|
|
INSERT INTO t1(a,b,c) VALUES (1,b'00', b'01');
|
|
|
|
|
REPLACE INTO t1(a,b,c) VALUES (2,b'00',b'01');
|
|
|
|
|
UPDATE t1 set b= NULL, c= b'00' where a= 1;
|
|
|
|
|
REPLACE INTO t1(a,b,c) VALUES (2, NULL, b'00');
|
|
|
|
|
************* SHOWING THE RESULT SETS WITH UPDATES and REPLACES *************
|
|
|
|
|
TABLES t1 and t2 must be equal otherwise an error will be thrown.
|
|
|
|
|
Comparing tables master:test.t1 and slave:test.t1
|
|
|
|
|
DROP TABLE t1;
|
|
|
|
|
################################################################################
|
|
|
|
|
# NULL ---> NOT NULL (STRICT MODE)
|
|
|
|
|
# UNCOMMENT THIS AFTER FIXING BUG#43992
|
|
|
|
|
################################################################################
|
|
|
|
|
################################################################################
|
|
|
|
|
# NULL ---> NOT NULL (NON-STRICT MODE)
|
|
|
|
|
################################################################################
|
|
|
|
|
SET SQL_LOG_BIN= 0;
|
|
|
|
|
CREATE TABLE t1(`a` INT NOT NULL, `b` INT,
|
|
|
|
|
PRIMARY KEY(`a`)) ENGINE=MyISAM DEFAULT CHARSET=LATIN1;
|
|
|
|
|
CREATE TABLE t2(`a` INT NOT NULL, `b` INT,
|
|
|
|
|
PRIMARY KEY(`a`)) ENGINE=MyISAM DEFAULT CHARSET=LATIN1;
|
|
|
|
|
CREATE TABLE t3(`a` INT NOT NULL, `b` INT,
|
|
|
|
|
PRIMARY KEY(`a`)) ENGINE=MyISAM DEFAULT CHARSET=LATIN1;
|
|
|
|
|
SET SQL_LOG_BIN= 1;
|
|
|
|
|
CREATE TABLE t1(`a` INT NOT NULL, `b` INT NOT NULL,
|
|
|
|
|
`c` INT NOT NULL,
|
|
|
|
|
PRIMARY KEY(`a`)) ENGINE=MyISAM DEFAULT CHARSET=LATIN1;
|
|
|
|
|
CREATE TABLE t2(`a` INT NOT NULL, `b` INT NOT NULL,
|
|
|
|
|
`c` INT,
|
|
|
|
|
PRIMARY KEY(`a`)) ENGINE=MyISAM DEFAULT CHARSET=LATIN1;
|
|
|
|
|
CREATE TABLE t3(`a` INT NOT NULL, `b` INT NOT NULL,
|
|
|
|
|
`c` INT DEFAULT 500,
|
|
|
|
|
PRIMARY KEY(`a`)) ENGINE=MyISAM DEFAULT CHARSET=LATIN1;
|
|
|
|
|
************* EXECUTION WITH INSERTS *************
|
|
|
|
|
INSERT INTO t1(a) VALUES (1);
|
|
|
|
|
INSERT INTO t1(a, b) VALUES (2, NULL);
|
|
|
|
|
INSERT INTO t1(a, b) VALUES (3, 1);
|
|
|
|
|
INSERT INTO t2(a) VALUES (1);
|
|
|
|
|
INSERT INTO t2(a, b) VALUES (2, NULL);
|
|
|
|
|
INSERT INTO t2(a, b) VALUES (3, 1);
|
|
|
|
|
INSERT INTO t3(a) VALUES (1);
|
|
|
|
|
INSERT INTO t3(a, b) VALUES (2, NULL);
|
|
|
|
|
INSERT INTO t3(a, b) VALUES (3, 1);
|
|
|
|
|
INSERT INTO t3(a, b) VALUES (4, 1);
|
|
|
|
|
REPLACE INTO t3(a, b) VALUES (5, null);
|
|
|
|
|
REPLACE INTO t3(a, b) VALUES (3, null);
|
|
|
|
|
UPDATE t3 SET b = NULL where a = 4;
|
|
|
|
|
************* SHOWING THE RESULT SETS *************
|
2009-10-22 01:19:52 +01:00
|
|
|
SELECT * FROM t1 ORDER BY a;
|
BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#43789 to mysql-5.1-bugteam
The replication was generating corrupted data, warning messages on Valgrind
and aborting on debug mode while replicating a "null" to "not null" field.
Specifically the unpack_row routine, was considering the slave's table
definition and trying to retrieve a field value, where there was nothing to be
retrieved, ignoring the fact that the value was defined as "null" by the master.
To fix the problem, we proceed as follows:
1 - If it is not STRICT sql_mode, implicit default values are used, regardless
if it is multi-row or single-row statement.
2 - However, if it is STRICT mode, then a we do what follows:
2.1 If it is a transactional engine, we do a rollback on the first NULL that is
to be set into a NOT NULL column and return an error.
2.2 If it is a non-transactional engine and it is the first row to be inserted
with multi-row, we also return the error. Otherwise, we proceed with the
execution, use implicit default values and print out warning messages.
Unfortunately, the current patch cannot mimic the behavior showed by the master
for updates on multi-tables and multi-row inserts. This happens because such
statements are unfolded in different row events. For instance, considering the
following updates and strict mode:
(master)
create table t1 (a int);
create table t2 (a int not null);
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
t1 would have (10) and t2 would have (0) as this would be handled as a
multi-row update. On the other hand, if we had the following updates:
(master)
create table t1 (a int);
create table t2 (a int);
(slave)
create table t1 (a int);
create table t2 (a int not null);
(master)
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
On the master t1 would have (10) and t2 would have (NULL). On
the slave, t1 would have (10) but the update on t1 would fail.
2009-10-22 01:15:45 +01:00
|
|
|
a b
|
|
|
|
|
1 NULL
|
|
|
|
|
2 NULL
|
|
|
|
|
3 1
|
2009-10-22 01:19:52 +01:00
|
|
|
SELECT * FROM t1 ORDER BY a;
|
BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#43789 to mysql-5.1-bugteam
The replication was generating corrupted data, warning messages on Valgrind
and aborting on debug mode while replicating a "null" to "not null" field.
Specifically the unpack_row routine, was considering the slave's table
definition and trying to retrieve a field value, where there was nothing to be
retrieved, ignoring the fact that the value was defined as "null" by the master.
To fix the problem, we proceed as follows:
1 - If it is not STRICT sql_mode, implicit default values are used, regardless
if it is multi-row or single-row statement.
2 - However, if it is STRICT mode, then a we do what follows:
2.1 If it is a transactional engine, we do a rollback on the first NULL that is
to be set into a NOT NULL column and return an error.
2.2 If it is a non-transactional engine and it is the first row to be inserted
with multi-row, we also return the error. Otherwise, we proceed with the
execution, use implicit default values and print out warning messages.
Unfortunately, the current patch cannot mimic the behavior showed by the master
for updates on multi-tables and multi-row inserts. This happens because such
statements are unfolded in different row events. For instance, considering the
following updates and strict mode:
(master)
create table t1 (a int);
create table t2 (a int not null);
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
t1 would have (10) and t2 would have (0) as this would be handled as a
multi-row update. On the other hand, if we had the following updates:
(master)
create table t1 (a int);
create table t2 (a int);
(slave)
create table t1 (a int);
create table t2 (a int not null);
(master)
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
On the master t1 would have (10) and t2 would have (NULL). On
the slave, t1 would have (10) but the update on t1 would fail.
2009-10-22 01:15:45 +01:00
|
|
|
a b c
|
|
|
|
|
1 0 0
|
|
|
|
|
2 0 0
|
|
|
|
|
3 1 0
|
2009-10-22 01:19:52 +01:00
|
|
|
SELECT * FROM t2 ORDER BY a;
|
BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#43789 to mysql-5.1-bugteam
The replication was generating corrupted data, warning messages on Valgrind
and aborting on debug mode while replicating a "null" to "not null" field.
Specifically the unpack_row routine, was considering the slave's table
definition and trying to retrieve a field value, where there was nothing to be
retrieved, ignoring the fact that the value was defined as "null" by the master.
To fix the problem, we proceed as follows:
1 - If it is not STRICT sql_mode, implicit default values are used, regardless
if it is multi-row or single-row statement.
2 - However, if it is STRICT mode, then a we do what follows:
2.1 If it is a transactional engine, we do a rollback on the first NULL that is
to be set into a NOT NULL column and return an error.
2.2 If it is a non-transactional engine and it is the first row to be inserted
with multi-row, we also return the error. Otherwise, we proceed with the
execution, use implicit default values and print out warning messages.
Unfortunately, the current patch cannot mimic the behavior showed by the master
for updates on multi-tables and multi-row inserts. This happens because such
statements are unfolded in different row events. For instance, considering the
following updates and strict mode:
(master)
create table t1 (a int);
create table t2 (a int not null);
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
t1 would have (10) and t2 would have (0) as this would be handled as a
multi-row update. On the other hand, if we had the following updates:
(master)
create table t1 (a int);
create table t2 (a int);
(slave)
create table t1 (a int);
create table t2 (a int not null);
(master)
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
On the master t1 would have (10) and t2 would have (NULL). On
the slave, t1 would have (10) but the update on t1 would fail.
2009-10-22 01:15:45 +01:00
|
|
|
a b
|
|
|
|
|
1 NULL
|
|
|
|
|
2 NULL
|
|
|
|
|
3 1
|
2009-10-22 01:19:52 +01:00
|
|
|
SELECT * FROM t2 ORDER BY a;
|
BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#43789 to mysql-5.1-bugteam
The replication was generating corrupted data, warning messages on Valgrind
and aborting on debug mode while replicating a "null" to "not null" field.
Specifically the unpack_row routine, was considering the slave's table
definition and trying to retrieve a field value, where there was nothing to be
retrieved, ignoring the fact that the value was defined as "null" by the master.
To fix the problem, we proceed as follows:
1 - If it is not STRICT sql_mode, implicit default values are used, regardless
if it is multi-row or single-row statement.
2 - However, if it is STRICT mode, then a we do what follows:
2.1 If it is a transactional engine, we do a rollback on the first NULL that is
to be set into a NOT NULL column and return an error.
2.2 If it is a non-transactional engine and it is the first row to be inserted
with multi-row, we also return the error. Otherwise, we proceed with the
execution, use implicit default values and print out warning messages.
Unfortunately, the current patch cannot mimic the behavior showed by the master
for updates on multi-tables and multi-row inserts. This happens because such
statements are unfolded in different row events. For instance, considering the
following updates and strict mode:
(master)
create table t1 (a int);
create table t2 (a int not null);
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
t1 would have (10) and t2 would have (0) as this would be handled as a
multi-row update. On the other hand, if we had the following updates:
(master)
create table t1 (a int);
create table t2 (a int);
(slave)
create table t1 (a int);
create table t2 (a int not null);
(master)
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
On the master t1 would have (10) and t2 would have (NULL). On
the slave, t1 would have (10) but the update on t1 would fail.
2009-10-22 01:15:45 +01:00
|
|
|
a b c
|
|
|
|
|
1 0 NULL
|
|
|
|
|
2 0 NULL
|
|
|
|
|
3 1 NULL
|
2009-10-22 01:19:52 +01:00
|
|
|
SELECT * FROM t3 ORDER BY a;
|
BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#43789 to mysql-5.1-bugteam
The replication was generating corrupted data, warning messages on Valgrind
and aborting on debug mode while replicating a "null" to "not null" field.
Specifically the unpack_row routine, was considering the slave's table
definition and trying to retrieve a field value, where there was nothing to be
retrieved, ignoring the fact that the value was defined as "null" by the master.
To fix the problem, we proceed as follows:
1 - If it is not STRICT sql_mode, implicit default values are used, regardless
if it is multi-row or single-row statement.
2 - However, if it is STRICT mode, then a we do what follows:
2.1 If it is a transactional engine, we do a rollback on the first NULL that is
to be set into a NOT NULL column and return an error.
2.2 If it is a non-transactional engine and it is the first row to be inserted
with multi-row, we also return the error. Otherwise, we proceed with the
execution, use implicit default values and print out warning messages.
Unfortunately, the current patch cannot mimic the behavior showed by the master
for updates on multi-tables and multi-row inserts. This happens because such
statements are unfolded in different row events. For instance, considering the
following updates and strict mode:
(master)
create table t1 (a int);
create table t2 (a int not null);
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
t1 would have (10) and t2 would have (0) as this would be handled as a
multi-row update. On the other hand, if we had the following updates:
(master)
create table t1 (a int);
create table t2 (a int);
(slave)
create table t1 (a int);
create table t2 (a int not null);
(master)
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
On the master t1 would have (10) and t2 would have (NULL). On
the slave, t1 would have (10) but the update on t1 would fail.
2009-10-22 01:15:45 +01:00
|
|
|
a b
|
|
|
|
|
1 NULL
|
|
|
|
|
2 NULL
|
|
|
|
|
3 NULL
|
|
|
|
|
4 NULL
|
|
|
|
|
5 NULL
|
2009-10-22 01:19:52 +01:00
|
|
|
SELECT * FROM t3 ORDER BY a;
|
BUG#48091 valgrind errors when slave has double not null and master has double null
Backporting BUG#43789 to mysql-5.1-bugteam
The replication was generating corrupted data, warning messages on Valgrind
and aborting on debug mode while replicating a "null" to "not null" field.
Specifically the unpack_row routine, was considering the slave's table
definition and trying to retrieve a field value, where there was nothing to be
retrieved, ignoring the fact that the value was defined as "null" by the master.
To fix the problem, we proceed as follows:
1 - If it is not STRICT sql_mode, implicit default values are used, regardless
if it is multi-row or single-row statement.
2 - However, if it is STRICT mode, then a we do what follows:
2.1 If it is a transactional engine, we do a rollback on the first NULL that is
to be set into a NOT NULL column and return an error.
2.2 If it is a non-transactional engine and it is the first row to be inserted
with multi-row, we also return the error. Otherwise, we proceed with the
execution, use implicit default values and print out warning messages.
Unfortunately, the current patch cannot mimic the behavior showed by the master
for updates on multi-tables and multi-row inserts. This happens because such
statements are unfolded in different row events. For instance, considering the
following updates and strict mode:
(master)
create table t1 (a int);
create table t2 (a int not null);
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
t1 would have (10) and t2 would have (0) as this would be handled as a
multi-row update. On the other hand, if we had the following updates:
(master)
create table t1 (a int);
create table t2 (a int);
(slave)
create table t1 (a int);
create table t2 (a int not null);
(master)
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
On the master t1 would have (10) and t2 would have (NULL). On
the slave, t1 would have (10) but the update on t1 would fail.
2009-10-22 01:15:45 +01:00
|
|
|
a b c
|
|
|
|
|
1 0 500
|
|
|
|
|
2 0 500
|
|
|
|
|
3 0 500
|
|
|
|
|
4 0 500
|
|
|
|
|
5 0 500
|
|
|
|
|
DROP TABLE t1;
|
|
|
|
|
DROP TABLE t2;
|
|
|
|
|
DROP TABLE t3;
|