MySQL Bugs: #51100: rpl_ndb.rpl_ndb_set

Bug #51100	rpl_ndb.rpl_ndb_set_null failed in 6.0
Submitted:	11 Feb 2010 14:19	Modified:	11 Feb 2010 16:26
Reporter:	Alexander Nozdrin	Email Updates:
Status:	Verified
Category:	Tests: Cluster	Severity:	S3 (Non-critical)
Version:	mysql-5.1-telco-6.2	OS:	Linux (x86_64 debug)
Assigned to:		Target Version:
Tags:	disabled, test failure, pb2

Description:
rpl_ndb.rpl_ndb_set_null fails in 6.0 on Linux x86_64 debug.

Symptoms are:
...
Could not execute Update_rows event on table test.t1; Can't find record in 't1',
Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's master log
master-bin.000001, end_log_pos 518
...

The test case will be disabled due to this bug in 6.0.

How to repeat:
See PB.

Sample of a failure:
http://pb2.norway.sun.com/web.py?template=mysql_show_test_failure&test_failure_id=2855854

I've had a look at this and I find it to fail locally as well. This
is what I found.

The test case (which was introduced in BUG#49481 fix) fails right
in the beginning. The first instructions are as simple as:

  MASTER> CREATE TABLE t1 (c1 BIT, c2 INT) Engine=NDB;
  MASTER> INSERT INTO `t1` VALUES ( 1, 1 );
  MASTER> UPDATE t1 SET c1=NULL where c2=1;
  MASTER> DELETE FROM t1 WHERE c2=1 LIMIT 1;

Now inspecting this with GDB, I find that there is something
wrong when searching in NDB. Here is what I find (BI, AI ->
stands for before and after image in the binlog event, SE ->
stands for storage engine):

  - INSERT processing (Write_rows_log_event::write_row)
   
     1. We reset the record
     2. We unpack the AI into the record
     3. We write the record in the SE

     while((error= table->file->ha_write_row(table->record[0]))) 
     {...}

     OBSERVATIONS:
       - Now at this point the contents of table->record[0] are:
         00000001 11110101

       - This makes sense (number 1 and bit field stored among
         the null_bits).

  - UPDATE processing (Update_rows_log_event::do_exec_row)

     1. We first locate the record in the storage engine using
        find_row. This stores SE record in table->record[0] and
        BI in table->record[1]. Since the table has unique
        keys (or any other key whatsoever) we do a table scan.
        Roughly:

        do 
        {
           error= table->file->rnd_next(table->record[0]);
           (...)
        } while(record_compare(BI, SE image))
         
     2. Then once the record is found we unpack on top of
        table->record[1] the contents of the AI (from the
        binlog). And apply it. Roughly:

        unpack_current_row(m_table->record[0]);
        (...)
        error= m_table->file->ha_update_row(m_table->record[1], 
                                            m_table->record[0]);

     OBSERVATIONS:
       - In #1, we get the following value in the unpacked BI:
         00000001 11110101

       - The value for BI is correct, judging from the value
         presented before in the Write_rows_event.

       - ** However, the value of error, got from rnd_next is 137. **

CONCLUSION: Seems that there is something in NDB SE reporting
            that the record cannot be found.

also fails in 6.2 when mergine 5.1.44