Bug #55944 Assertion: node->pcur->rel_pos == BTR_PCUR_ON on DELETE after EXCHANGE PARTITION
Submitted: 12 Aug 2010 12:34 Modified: 16 Nov 2010 1:42
Reporter: Elena Stepanova Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: Partitions Severity:S3 (Non-critical)
Version:5.6.0-m4, 5.6.1-m4 OS:Any
Assigned to: Assigned Account CPU Architecture:Any
Triage: Triaged: D1 (Critical)

[12 Aug 2010 12:34] Elena Stepanova
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;
[25 Aug 2010 11:53] Mattias Jonsson
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.
[29 Oct 2010 10:23] Mattias Jonsson
Removal of the IGNORE option is proposed to be removed in bug#57708.
[16 Nov 2010 1:42] Mattias Jonsson
Duplicate of bug#57708 (IGNORE was removed there, so this bug cannot happen any longer).
[13 Dec 2010 6:43] Jon Stephens
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.
[13 Dec 2010 8:54] Mattias Jonsson
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.