Luis Soares fbe81e3c97 BUG#52868: Wrong handling of NULL value during update, replication out ... of sync In RBR, sometimes the table->s->last_null_bit_pos can be zero. This has impact at the slave when it compares records fetched from the storage engine against records in the binary log event. If last_null_bit_pos is zero the slave, while comparing in log_event.cc:record_compare function, would set all bits in the last null_byte to 1 (assumed all 8 were unused) . Thence it would loose the ability to distinguish records that were similar in contents except for the fact that some field was null in one record, but not in the other. Ultimately this would cause wrong matches, and in the specific case depicted in the bug report the same record would be updated twice, resulting in a lost update. Additionally, in the record_compare function the slave was setting the X bit unconditionally. There are cases that the X bit does not exist in the record header. This could also lead to wrong matches between records. We fix both by conditionally resetting the bits: (i) unused null_bits are set if last_null_bit_pos > 0; (ii) X bit is set if HA_OPTION_PACK_RECORD is in use. mysql-test/extra/rpl_tests/rpl_record_compare.test: Shared part of the test case for MyISAM and InnoDB. mysql-test/suite/rpl/t/rpl_row_rec_comp_innodb.test: InnoDB test case. mysql-test/suite/rpl/t/rpl_row_rec_comp_myisam.test: MyISAM test case. Added also coverage for Field_bits case. sql/log_event.cc: Deployed conditional setting of unused bits at record_compare. sql/log_event_old.cc: Same change as in log_event.cc.		2010-04-21 13:47:55 +01:00
..
binlog_tests	Manual Merge	2009-11-03 18:20:08 +08:00
rpl_tests	BUG#52868: Wrong handling of NULL value during update, replication out	2010-04-21 13:47:55 +01:00