Core was generated by `/test/MD171122-mariadb-10.11.2-linux-x86_64-dbg/bin/mysqld --no-defaults --core'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
[Current thread is 1 (Thread 0x14d2316c0700 (LWP 2750433))]
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x000014d24a822859 in __GI_abort () at abort.c:79
#2 0x000014d24a822729 in __assert_fail_base (fmt=0x14d24a9b8588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x555d6fc34ee7 "!error", file=0x555d6fc9b9d8 "/test/10.11_dbg/sql/ha_partition.cc", line=4782, function=<optimized out>) at assert.c:92
#3 0x000014d24a833fd6 in __GI___assert_fail (assertion=assertion@entry=0x555d6fc34ee7 "!error", file=file@entry=0x555d6fc9b9d8 "/test/10.11_dbg/sql/ha_partition.cc", line=line@entry=4782, function=function@entry=0x555d6fc9c2c8 "virtual int ha_partition::delete_row(const uchar*)") at assert.c:101
#4 0x0000555d6f45e9e3 in ha_partition::delete_row (this=0x14d1ec0e70e0, buf=0x14d1ec0d9d78 "\377") at /test/10.11_dbg/sql/ha_partition.cc:4782
#5 0x0000555d6f1d3785 in handler::ha_delete_row (this=0x14d1ec0e70e0, buf=0x14d1ec0d9d78 "\377") at /test/10.11_dbg/sql/handler.cc:7700
#6 0x0000555d6ee96021 in TABLE::delete_row (this=0x14d1ec0cf708) at /test/10.11_dbg/sql/sql_delete.cc:281
#7 multi_delete::do_table_deletes (this=this@entry=0x14d1ec016128, table=table@entry=0x14d1ec0cf708, sort_info=<optimized out>, ignore=false) at /test/10.11_dbg/sql/sql_delete.cc:1557
#8 0x0000555d6ee96305 in multi_delete::do_deletes (this=this@entry=0x14d1ec016128) at /test/10.11_dbg/sql/sql_delete.cc:1503
#9 0x0000555d6ee9638c in multi_delete::send_eof (this=0x14d1ec016128) at /test/10.11_dbg/sql/sql_delete.cc:1611
#10 0x0000555d6ef72c6d in do_select (procedure=<optimized out>, join=0x14d1ec016198) at /test/10.11_dbg/sql/sql_select.cc:21414
#11 JOIN::exec_inner (this=this@entry=0x14d1ec016198) at /test/10.11_dbg/sql/sql_select.cc:4823
#12 0x0000555d6ef72fd4 in JOIN::exec (this=this@entry=0x14d1ec016198) at /test/10.11_dbg/sql/sql_select.cc:4601
#13 0x0000555d6ef70f88 in mysql_select (thd=thd@entry=0x14d1ec000d48, tables=0x14d1ec0140f0, fields=@0x14d1ec005a58: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x14d1ec015f40, last = 0x14d1ec015f40, elements = 1}, <No data fields>}, conds=conds@entry=0x0, og_num=og_num@entry=0, order=order@entry=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=37385559870336, result=0x14d1ec016128, unit=0x14d1ec004f88, select_lex=0x14d1ec0057b8) at /test/10.11_dbg/sql/sql_select.cc:5081
#14 0x0000555d6eeedb55 in mysql_execute_command (thd=thd@entry=0x14d1ec000d48, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/10.11_dbg/sql/sql_parse.cc:4864
#15 0x0000555d6eed9606 in mysql_parse (thd=thd@entry=0x14d1ec000d48, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x14d2316bf300) at /test/10.11_dbg/sql/sql_parse.cc:7998
#16 0x0000555d6eee6b41 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x14d1ec000d48, packet=packet@entry=0x14d1ec00adf9 "DELETE FROM a2,a1 USING t1 AS a1 JOIN t1 AS a2,t1 AS a3", packet_length=packet_length@entry=55, blocking=blocking@entry=true) at /test/10.11_dbg/sql/sql_class.h:1346
#17 0x0000555d6eee8f7f in do_command (thd=0x14d1ec000d48, blocking=blocking@entry=true) at /test/10.11_dbg/sql/sql_parse.cc:1407
#18 0x0000555d6f043763 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x555d7296a678, put_in_cache=put_in_cache@entry=true) at /test/10.11_dbg/sql/sql_connect.cc:1416
#19 0x0000555d6f043c32 in handle_one_connection (arg=0x555d7296a678) at /test/10.11_dbg/sql/sql_connect.cc:1318
#20 0x000014d24ad33609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#21 0x000014d24a91f133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
The error is legitimate, so the question is whether the assert is necessary. One possible solution to this issue is to try to detect the incomplete coverage of the partitions over the data node table rows earlier in the DELETE statement when opening the partition table, but I don't see how to justify the extra complexity introduced by this change as well as the fact that it is basically doing the same check as at the assertion failure, if we could simply remove the assert. Therefore my patch proposes the removal of the assertion.
Hi serg, since you added the assertion I'm asking you to review this change, ptal thanks
3116ab76fe9 upstream/bb-10.5-mdev-30067 bb-10.5-ycp MDEV-30067 Remove an overly enthusiastic assert when deleting from a partitioned table
Yuchen Pei
added a comment - The error is legitimate, so the question is whether the assert is necessary. One possible solution to this issue is to try to detect the incomplete coverage of the partitions over the data node table rows earlier in the DELETE statement when opening the partition table, but I don't see how to justify the extra complexity introduced by this change as well as the fact that it is basically doing the same check as at the assertion failure, if we could simply remove the assert. Therefore my patch proposes the removal of the assertion.
Hi serg , since you added the assertion I'm asking you to review this change, ptal thanks
3116ab76fe9 upstream/bb-10.5-mdev-30067 bb-10.5-ycp MDEV-30067 Remove an overly enthusiastic assert when deleting from a partitioned table
then you need to remove the second assertion as well. With spider you can easily have a row belonging to a wrong partition, so there will be no error, but the partition number will be wrong.
please, add a test case for that too.
and if you remove both asserts, then what value does this #ifdef block has? you can remove get_part_for_buf() too. And part of the comment, which will be no longer relevant. Only a couple of lines of the comment and bitmap_is_set() can stay.
Sergei Golubchik
added a comment - then you need to remove the second assertion as well. With spider you can easily have a row belonging to a wrong partition, so there will be no error, but the partition number will be wrong.
please, add a test case for that too.
and if you remove both asserts, then what value does this #ifdef block has? you can remove get_part_for_buf() too. And part of the comment, which will be no longer relevant. Only a couple of lines of the comment and bitmap_is_set() can stay.
Thanks for the comment, ptal at the updated commit:
fa3656ab1ff upstream/bb-10.5-mdev-30067 MDEV-30067 Remove some overly enthusiastic asserts when deleting from a partitioned table
Addressing your comments:
> then you need to remove the second assertion as well. With spider you can easily have a row belonging to a wrong partition, so there will be no error, but the partition number will be wrong.
> please, add a test case for that too.
Done.
> and if you remove both asserts, then what value does this #ifdef block has? you can remove get_part_for_buf() too. And part of the comment, which will be no longer relevant. Only a couple of lines of the comment and bitmap_is_set() can stay.
Removed get_part_for_buf() and trimmed the comment accordingly. The remaining asserts are not tripped w.r.t. this issue so there's no reason to remove them here to my knowledge.
Yuchen Pei
added a comment - Hi serg ,
Thanks for the comment, ptal at the updated commit:
fa3656ab1ff upstream/bb-10.5-mdev-30067 MDEV-30067 Remove some overly enthusiastic asserts when deleting from a partitioned table
Addressing your comments:
> then you need to remove the second assertion as well. With spider you can easily have a row belonging to a wrong partition, so there will be no error, but the partition number will be wrong.
> please, add a test case for that too.
Done.
> and if you remove both asserts, then what value does this #ifdef block has? you can remove get_part_for_buf() too. And part of the comment, which will be no longer relevant. Only a couple of lines of the comment and bitmap_is_set() can stay.
Removed get_part_for_buf() and trimmed the comment accordingly. The remaining asserts are not tripped w.r.t. this issue so there's no reason to remove them here to my knowledge.
Bug
Major
The error is legitimate, so the question is whether the assert is necessary. One possible solution to this issue is to try to detect the incomplete coverage of the partitions over the data node table rows earlier in the DELETE statement when opening the partition table, but I don't see how to justify the extra complexity introduced by this change as well as the fact that it is basically doing the same check as at the assertion failure, if we could simply remove the assert. Therefore my patch proposes the removal of the assertion.
Hi serg, since you added the assertion I'm asking you to review this change, ptal thanks
3116ab76fe9 upstream/bb-10.5-mdev-30067 bb-10.5-ycp MDEV-30067 Remove an overly enthusiastic assert when deleting from a partitioned table