MySQL Bugs: #27077: ndb->extra(HA_EXTRA_IGNORE_NO_KEY) becomes repeatedl ineffectiv once was reset

Bug #27077	ndb->extra(HA_EXTRA_IGNORE_NO_KEY) becomes repeatedl ineffectiv once was reset
Submitted:	13 Mar 2007 10:46	Modified:	11 Jun 2009 17:07
Reporter:	Andrei Elkin	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Cluster: Replication	Severity:	S3 (Non-critical)
Version:	mysql-5.1	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	5.1.17

Description:
HA_EXTRA_NO_IGNORE_NO_KEY.

There is a patch for Bug#27044 that essentially completes execution of
   table->file->write_row()
with resetting of
   table->file->extra(no-sematics-argument)-s 
in generic replication code (log_even.cc). Resetting is done because 
before write_row is called there were table->file->extra(yes-sematics-argument).

The patched replication code looks as
   table->file->extra(yes-sematics-argument)
   table->file->write_row()
   table->file->extra(no-sematics-argument)  // added by the patch

This code sustains basically all tests except rpl_ndb_idempotent.test where
ndb handler reports an error that was not supposed to happen.

Note, that other engines like myisam, heap, innodb do not create a situation
described in How-2-repeat.

How to repeat:
apply patch for Bug #27044 and execute
mysql-test-run.pl --mysqld=--binlog-format=row t/rpl_ndb_idempotent.test

to find out that the final update from master 
     UPDATE t1 SET c2="does not exist" WHERE c3=1;
triggered the error and that is NOT supposed to happen.

Finer simpler test is just to execute the final part of the test, in which
synch won't happen because slave must hang due to UPDATE

--connection master
CREATE TABLE t1 (c1 CHAR(15) NOT NULL, c2 CHAR(15) NOT NULL, c3 INT NOT NULL, PRIMARY KEY (c3)) ENGINE = NDB ;
INSERT INTO t1 VALUES ("row1","remove on slave",1);

--sync_slave_with_master
--connection slave
DELETE FROM t1;

--connection master
BEGIN;
UPDATE t1 SET c2="does not exist" WHERE c3=1;
INSERT INTO t1 VALUES ("row2","new on slave",2);
COMMIT;

--sync_slave_with_master

Taking on myself to analyze the case better.

Closing it though smells bad.
What remains wondering me is that 
an attempt to set ndb's mood in  Write_rows_log_event::do_before_row_operations with
  table->file->extra(HA_EXTRA_IGNORE_NO_KEY);
and reset at Write_rows_log_event::do_after_row_operations with
  table->file->extra(HA_EXTRA_NO_IGNORE_NO_KEY);

creates a side effect: slave stops with 
                 Last_Errno: 839
                 Last_Error: Error in Write_rows event: error during transaction execution on table test.t1

when executing the reported piece of rpl_ndb_idempotent
Needs discussing with cluster team.

Tested how possibly fix for Bug #27320 ndb handler does not reset extra flags on reset() could affect the current case.

The reported test still fails if 
int Write_rows_log_event::do_after_row_operations()
executed the matching (to do_before_row_operations

    table->file->extra(HA_EXTRA_NO_IGNORE_NO_KEY); 

rpl_ndb_idempotent             [ fail ]

Errors are (from /tmp/andrei/mysql-5.1-new-rpl/mysql-test/var/log/mysqltest-time) :
mysqltest: At line 106: could not sync with master ('select master_pos_wait('master-bin.000001', 1007)' returned NULL)

slave.err:

070502 17:17:28 [ERROR] Slave: Error in Write_rows event: error during transaction execution on table test.t1, Error_code: 839
070502 17:17:28 [ERROR] Slave (additional info): Unknown error Error_code: 1105
070502 17:17:28 [Warning] Slave: Got error 839 'Illegal null attribute' from NDB Error_code: 1296
070502 17:17:28 [Warning] Slave: Unknown error Error_code: 1105
070502 17:17:28 [ERROR] Error running query, slave SQL thread aborted.

Pushed into 5.1.20-beta

"Pushed" should be ignored - a mistake of pushbuild buglist generator.

Still and issues?