Bug #51100 rpl_ndb.rpl_ndb_set_null failed in 6.0
Submitted: 11 Feb 2010 14:19 Modified: 15 Nov 2018 11:32
Reporter: Alexander Nozdrin Email Updates:
Status: Duplicate Impact on me:
None 
Category:Tests: Cluster Severity:S3 (Non-critical)
Version:mysql-5.1-telco-6.2 OS:Linux (x86_64 debug)
Assigned to: CPU Architecture:Any
Tags: disabled, pb2, test failure

[11 Feb 2010 14:19] Alexander Nozdrin
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.
[11 Feb 2010 16:25] Luis Soares
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.
[12 Mar 2010 13:48] Jonas Oreland
also fails in 6.2 when mergine 5.1.44
[15 Nov 2018 11:32] Magnus BlÄudd
Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments to the original bug instead.

Thank you for your interest in MySQL.