Bug #55944 Assertion: node->pcur->rel_pos == BTR_PCUR_ON on DELETE after EXCHANGE PARTITION

Description:
After EXCHANGE PARTITION .. IGNORE on an InnoDB table partitioned by list, DELETE causes assertion:

100812 15:24:51  InnoDB: Assertion failure in thread 1166592320 in file mysql-5.6.1-m4/storage/innobase/row/row0mysql.c line 1421
InnoDB: Failing assertion: node->pcur->rel_pos == BTR_PCUR_ON
InnoDB: We intentionally generate a memory trap.

#4  0x00002ba16abbcfb0 in abort () from /lib64/libc.so.6
#5  0x000000000079f9cc in row_update_for_mysql (mysql_rec=<value optimized out>, prebuilt=0x1614ab8)
    at mysql-5.6.1-m4/storage/innobase/row/row0mysql.c:1421
#6  0x0000000000785d9a in ha_innobase::delete_row (this=0x15ea5e0, record=0x15ea508 "Щ\001")
    at mysql-5.6.1-m4/storage/innobase/handler/ha_innodb.cc:5321
#7  0x0000000000652233 in handler::ha_delete_row (this=0x15ea5e0, buf=0x15ea508 "Щ\001")
    at mysql-5.6.1-m4/sql/handler.cc:4940
#8  0x0000000000646c5c in ha_partition::delete_row (this=0x15ea1f0, buf=0x15ea508 "Щ\001")
    at mysql-5.6.1-m4/sql/ha_partition.cc:3308
#9  0x0000000000652233 in handler::ha_delete_row (this=0x15ea1f0, buf=0x15ea508 "Щ\001")
    at mysql-5.6.1-m4/sql/handler.cc:4940
#10 0x0000000000712c10 in mysql_delete (thd=0x1560720, table_list=0x16346a8, conds=0x0, order_list=<value optimized out>, limit=18446744073709551615, options=0)
    at mysql-5.6.1-m4/sql/sql_delete.cc:313
#11 0x0000000000560780 in mysql_execute_command (thd=0x1560720) at mysql-5.6.1-m4/sql/sql_parse.cc:3268
#12 0x00000000005636c3 in mysql_parse (thd=0x1560720, rawbuf=<value optimized out>, length=<value optimized out>, parser_state=0x4588bcf0)
    at mysql-5.6.1-m4/sql/sql_parse.cc:5828
#13 0x0000000000564c75 in dispatch_command (command=<value optimized out>, thd=0x1560720, packet=0x1629871 "DELETE FROM t_part_list",
    packet_length=<value optimized out>) at mysql-5.6.1-m4/sql/sql_parse.cc:1129
#14 0x00000000005f1b66 in do_handle_one_connection (thd_arg=<value optimized out>)
    at mysql-5.6.1-m4/sql/sql_connect.cc:1191
#15 0x00000000005f1eb4 in handle_one_connection (arg=<value optimized out>)
    at mysql-5.6.1-m4/sql/sql_connect.cc:1130
#16 0x00000000008ee9fb in pfs_spawn_thread (arg=<value optimized out>)
    at mysql-5.6.1-m4/storage/perfschema/pfs.cc:1061
#17 0x00002ba16a5dd143 in start_thread () from /lib64/libpthread.so.0
#18 0x00002ba16ac4c8cd in clone () from /lib64/libc.so.6
#19 0x0000000000000000 in ?? ()

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x16345c0 = DELETE FROM t_part_list
thd->thread_id=2
thd->killed=NOT_KILLED

How to repeat:
CREATE TABLE t ( i INT ) ENGINE = InnoDB;
CREATE TABLE t_part_list ( i INT ) ENGINE = InnoDB 
   PARTITION BY LIST (i) 
   ( PARTITION p0 VALUES IN (1,3), PARTITION p1 VALUES IN (2,4) );
INSERT INTO t_part_list VALUES (1),(2),(3),(4);

ALTER TABLE t_part_list EXCHANGE PARTITION p0 WITH TABLE t;
ALTER TABLE t_part_list EXCHANGE PARTITION p1 WITH TABLE t IGNORE;

DELETE FROM t_part_list;

DROP TABLE t_part_list, t;

After some discussion with Mikael and Svoj, I will try to add a state per partition in the .par file, which is set to MAY_HAVE_NON_MATCHING_ROWS when exchanging data into a partition, and which is reset on CHECK/REPAIR (also need to be added).

If MAY_HAVE_NON_MATCHING_ROWS is set for a partition, it needs to verify each row on read, that it matches the partition otherwise we should mark the table as crashed.

Removal of the IGNORE option is proposed to be removed in bug#57708.

Duplicate of bug#57708 (IGNORE was removed there, so this bug cannot happen any longer).

Please note that the correct syntax should be "ALTER IGNORE TABLE tbl_1_name EXCHANGE PARTITION paretition_name WITH TABLE tbl_2_name" -- this is standard for all ALTER TABLE statements.

Please note that 'ALTER IGNORE TABLE tbl_1 EXCHANGE PARTITION p0 WITH TABLE tbl_2' ignores the 'IGNORE'.
Also since bug#57708 'ALTER TABLE tbl_1 EXCHANGE PARTITION p0 WITH TABLE tbl_2 IGNORE' the 'IGNORE' part is not supported.