MySQL Bugs: #13418: row based replication replication of bit and NULL cause core or wrong values

Bug #13418	row based replication replication of bit and NULL cause core or wrong values
Submitted:	23 Sep 2005 4:48	Modified:	27 Feb 2006 19:38
Reporter:	Tomas Ulin	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S2 (Serious)
Version:	5.1-wl2325, 5.0-wl1012?	OS:
Assigned to:	Lars Thalmann	CPU Architecture:	Any

Description:

NOTE: there are 2 test cases below... the error is in the same place in the code...

I got this in the 5.1-wl2325 without cluster, so I think it is in 5.0-wl1012

also code does not look right for comparing bitfields in record_compare that's why I originally tested this.  The update below should come out wrong on the slave side either for

update set a = 2 where b = b'1';

or

update set a = 2 where b = b'0';

Unfortunatly cannot test because slave cores on me...

The other error has to do with NULL... see test case after core snip

How to repeat:
master:

create table t1 (a int, b bit(1));
insert into t1 (1, b'0');
insert into t1 (1, b'1');
update set a = 2 where b = b'1';

slave:

start slave;

-> core in debug

#12 0x08228561 in close_thread_table(THD*, st_table**) (thd=0x8905d20, table_ptr=0x89064dc) at sql_base.cc:549
549       DBUG_ASSERT(table->file->inited == handler::NONE);
(gdb) 
#13 0x082283a6 in close_thread_tables(THD*, bool, bool) (thd=0x8905d20, lock_in_use=false, skip_derived=false) at sql_base.cc:512
512         found_old_table|=close_thread_table(thd, &thd->open_tables);
(gdb) 
#14 0x0828cc04 in Rows_log_event::exec_event(st_relay_log_info*) (this=0x8914db8, rli=0x88ddfbc) at log_event.cc:5249
5249        close_thread_tables(thd);
(gdb) 

create table t1 (a int, b int);
insert into t1 values (1, NULL);
insert into t1 values (1, 0);
update t1 set a = 2 where b = 0;
select * from t1;
+------+------+
| a    | b    |
+------+------+
|    1 | NULL |
|    2 |    0 |
+------+------+
2 rows in set (0.00 sec)

on slave:

select * from t1;
+------+------+
| a    | b    |
+------+------+
|    2 |    0 |
|    1 |    0 |
+------+------+
2 rows in set (0.00 sec)

First test for me produced:
050923 14:32:09 [ERROR] Slave: Error in Update_rows event: row application failed, Error_code: 137
050923 14:32:09 [ERROR] Slave: Error in Update_rows event: error during transaction execution on table test.t2, Error_code: 137

Second test showed what Tomas had:
+ SELECT * FROM test.t3;
+ a     b
+ 1     NULL
+ 2     0
+ SELECT * FROM test.t3;
+ a     b
+ 2     0
+ 1     0

Have been added to rpl_bit_npk.test and had been disabled in disabled.def and pushed into the clone.

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/3102

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/3112

This has been pushed into 5.1.7.  The fix is in two parts:

1. The Field_bit object did not have a correct comparison method
which can potentially lead to wrong results (also in other areas than RBR, 
but we have not, as far as I know, seen any bugs resulting from this).

2. The comparision for RBR did not work for bit fields and NULL 
values .  This has been corrected by fixing the RBR compare function.

Part 1 should also be pushed into 5.0 and this report can be closed 
when that has happened.

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/3206

Fix 1 has been pushed to 5.0.19.

Documented in 5.0.19 changelogs:

  <listitem>
        <para>
          <literal>BIT</literal> fields were not properly handled when
          using row-based replication. (Bug #13418)
        </para>
      </listitem>

Noted in 5.1.7 changelog as well.