[MDEV-20618] Assertion `btr_validate_index(index, 0, false)' failed in row_upd_sec_index_entry - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Critical
Resolution: Fixed
Affects Version/s: 10.5.1, 10.2(EOL), 10.3(EOL), 10.4(EOL)
Fix Version/s: 10.2.35, 10.3.26, 10.4.16, 10.5.7
Component/s: Storage Engine - InnoDB, Virtual Columns
Labels:

Description

--source include/have_innodb.inc

create table t1 ( a bit(15), va bit(10) generated always as (a),pk int, primary key (pk), unique key (va)) engine=innodb;

insert ignore into t1 values ( '\r1','a',1);

replace into t1 (pk) values (1);

10.2 273d8eb12c40a6dc
#3 <signal handler called>
#4 0x00007f369b694428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#5 0x00007f369b69602a in __GI_abort () at abort.c:89
#6 0x00007f369b68cbd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x560a446b8248 "btr_validate_index(index, 0, false)", file=file@entry=0x560a446b7cc8 "/10.2/storage/innobase/row/row0upd.cc", line=line@entry=2440, function=function@entry=0x560a446bae00 <row_upd_sec_index_entry(upd_node_t, que_thr_t)::__PRETTY_FUNCTION__> "dberr_t row_upd_sec_index_entry(upd_node_t, que_thr_t)") at assert.c:92
#7 0x00007f369b68cc82 in __GI___assert_fail (assertion=0x560a446b8248 "btr_validate_index(index, 0, false)", file=0x560a446b7cc8 "/10.2/storage/innobase/row/row0upd.cc", line=2440, function=0x560a446bae00 <row_upd_sec_index_entry(upd_node_t, que_thr_t)::__PRETTY_FUNCTION__> "dberr_t row_upd_sec_index_entry(upd_node_t, que_thr_t)") at assert.c:101
#8 0x0000560a441b35e0 in row_upd_sec_index_entry (node=0x7f3640186a50, thr=0x7f3640084fa8) at /10.2/storage/innobase/row/row0upd.cc:2440
#9 0x0000560a441b3c7f in row_upd_sec_step (node=0x7f3640186a50, thr=0x7f3640084fa8) at /10.2/storage/innobase/row/row0upd.cc:2554
#10 0x0000560a441b5ef9 in row_upd (node=0x7f3640186a50, thr=0x7f3640084fa8) at /10.2/storage/innobase/row/row0upd.cc:3310
#11 0x0000560a441b624b in row_upd_step (thr=0x7f3640084fa8) at /10.2/storage/innobase/row/row0upd.cc:3427
#12 0x0000560a4415e8ad in row_update_for_mysql (prebuilt=0x7f3640185f08) at /10.2/storage/innobase/row/row0mysql.cc:1828
#13 0x0000560a44023b91 in ha_innobase::delete_row (this=0x7f36401850c8, record=0x7f364000a5e0 "\241\r1\001") at /10.2/storage/innobase/handler/ha_innodb.cc:9136
#14 0x0000560a43ce7516 in handler::ha_delete_row (this=0x7f36401850c8, buf=0x7f364000a5e0 "\241\r1\001") at /10.2/sql/handler.cc:6149
#15 0x0000560a43a347fe in write_record (thd=0x7f3640000b00, table=0x7f36400099c0, info=0x7f368c4fa360) at /10.2/sql/sql_insert.cc:1905
#16 0x0000560a43a323f6 in mysql_insert (thd=0x7f3640000b00, table_list=0x7f3640012550, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_REPLACE, ignore=false) at /10.2/sql/sql_insert.cc:1066
#17 0x0000560a43a59414 in mysql_execute_command (thd=0x7f3640000b00) at /10.2/sql/sql_parse.cc:4167
#18 0x0000560a43a64bc9 in mysql_parse (thd=0x7f3640000b00, rawbuf=0x7f3640012468 "replace into t1 (pk) values (1)", length=31, parser_state=0x7f368c4fb080, is_com_multi=false, is_next_command=false) at /10.2/sql/sql_parse.cc:7759
#19 0x0000560a43a52e8c in dispatch_command (command=COM_QUERY, thd=0x7f3640000b00, packet=0x7f3640096131 "replace into t1 (pk) values (1)", packet_length=31, is_com_multi=false, is_next_command=false) at /10.2/sql/sql_parse.cc:1831
#20 0x0000560a43a517a0 in do_command (thd=0x7f3640000b00) at /10.2/sql/sql_parse.cc:1385
#21 0x0000560a43ba7795 in do_handle_one_connection (connect=0x560a465941d0) at /10.2/sql/sql_connect.cc:1336
#22 0x0000560a43ba7500 in handle_one_connection (arg=0x560a465941d0) at /10.2/sql/sql_connect.cc:1241
#23 0x0000560a443d4168 in pfs_spawn_thread (arg=0x560a4659efc0) at /10.2/storage/perfschema/pfs.cc:1862
#24 0x00007f369c2d16ba in start_thread (arg=0x7f368c4fc700) at pthread_create.c:333
#25 0x00007f369b76641d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Attachments

Issue Links

causes

MDEV-24786 Assertion `!have_x()' failed in sux_lock<srw>::s_lock() [with srw = ssux_lock_low]

Closed

is caused by

MDEV-5800 indexes on virtual (not materialized) columns

Closed

is duplicated by

MDEV-17834 Server crashes in row_upd_build_difference_binary on LOAD DATA into table with indexed virtual column

Closed

MDEV-17890 Server crash on DELETE with YEAR field with truncated expr

Closed

MDEV-20089 Unhide failed compute vcol value warning

Closed

relates to

MDEV-17837 Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed upon REPLACE on table with out-of-range value in virtual column

Closed

MDEV-18153 Assertion `0' or Assertion `btr_validate_index(index, 0)' failed in row_upd_sec_index_entry or error code 126: Index is corrupted upon UPDATE with TIME_ROUND_FRACTIONAL

Closed

MDEV-18156 Assertion `0' failed or `btr_validate_index(index, 0, false)' in row_upd_sec_index_entry or error code 126: Index is corrupted upon DELETE with PAD_CHAR_TO_FULL_LENGTH

Closed

MDEV-19771 REPLACE on table with virtual_field can cause crash in set_ok_status()

Closed

MDEV-20423 Assertion `0' failed or `btr_validate_index(index, 0, false)' in row_upd_sec_index_entry or error code 126: Index is corrupted upon DELETE with TIME_ROUND_FRACTIONAL

Closed

MDEV-20610 Assertion failed or btr_validate_index(..) in row_upd_sec_index_entry on a time_zone change

Stalled

MDEV-20661 Virtual fields are not recalculated on system fields value assignment

Closed

MDEV-20763 Table corruption or Assertion `btr_validate_index(index, 0, false)' failed in row_upd_sec_index_entry with virtual column and EMPTY_STRING_IS_NULL SQL mode

Closed

MDEV-22061 InnoDB: Assertion of missing row in sec index row_start upon REPLACE on a system-versioned table

Closed

MDEV-26405 Assertion `0' failed in row_upd_sec_index_entry

Closed

(10 relates to)

Activity

Ascending order - Click to sort in descending order

Alexander Barkov added a comment - 2019-09-25 04:06 - edited

Another script that repeats the problem:

create or replace table t1 (a bit(15), va bit(10) generated always as (a),pk int, primary key (pk), unique key (va)) engine=innodb;

insert ignore into t1 values (0x400,0,1);

replace into t1 (pk) values (1);

The maximum possible value for the generated column va is 0x3FF.
This scripts inserts 0x400 to the regular column a, so 0x400 gets truncated to 0x3FF when being copied to va.

The same problem is repeatable with a simplified script:

create or replace table t1 (a bit(15), va bit(10) generated always as (a),pk int, primary key (pk), unique key (va)) engine=innodb;

insert ignore into t1 (a,pk) values (0x400,1);

replace into t1 (pk) values (1);

Alexander Barkov added a comment - 2019-09-25 04:06 - edited Another script that repeats the problem: create or replace table t1 (a bit (15), va bit (10) generated always as (a),pk int , primary key (pk), unique key (va)) engine=innodb; insert ignore into t1 values (0x400,0,1); replace into t1 (pk) values (1); The maximum possible value for the generated column va is 0x3FF . This scripts inserts 0x400 to the regular column a , so 0x400 gets truncated to 0x3FF when being copied to va . The same problem is repeatable with a simplified script: create or replace table t1 (a bit (15), va bit (10) generated always as (a),pk int , primary key (pk), unique key (va)) engine=innodb; insert ignore into t1 (a,pk) values (0x400,1); replace into t1 (pk) values (1);

Alexander Barkov added a comment - 2019-09-25 04:13

marko, can you please investigate this problem? Thanks.

Alexander Barkov added a comment - 2019-09-25 04:13 marko , can you please investigate this problem? Thanks.

Matthias Leich added a comment - 2020-02-03 12:41

Observed in 10.5.1
10.5 287c1db7867502348dcbc9ff7ccaae3d289cdbb1 2020-02-03T17:59:14+08:00
too.

Matthias Leich added a comment - 2020-02-03 12:41 Observed in 10.5.1 10.5 287c1db7867502348dcbc9ff7ccaae3d289cdbb1 2020-02-03T17:59:14+08:00 too.

Marko Mäkelä added a comment - 2020-02-04 12:06

I just checked this in a 10.5-based branch:

create table t1 (a bit(15), va bit(10) generated always as (a),pk int, primary key (pk), unique key (va)) engine=innodb;

insert ignore into t1 values (0x400,0,1);

Warnings:

Warning	1906	The value specified for generated column 'va' in table 't1' has been ignored

Warning	1264	Out of range value for column 'va' at row 1

replace into t1 (pk) values (1);

An assertion fails during the REPLACE, similar to the Description. The index contents are as follows:
(pk,DB_TRX_ID,DB_ROLL_PTR,a)=delete-marked(1,32,…,0x400) (delete-marked by the current transaction)
(va,pk)=(0x3ff,1)

We fail to find the secondary index record, because we are searching for an index entry of (va,pk)=(NULL,1) instead of (0x3ff,1).

The problem seems to be that INSERT IGNORE is replacing the out-of-range bitmap value 0x400 with 0x3ff, while REPLACE is substituting NULL.

I think that INSERT IGNORE must always compute indexed virtual column values in a way that is compatible with everything else. If virtual column values are materialized in an index or table, they must be evaluated consistently in all cases.

Perhaps the IGNORE should be ignored altogether when indexed virtual columns exist, and the statement should return an error in this case?

Marko Mäkelä added a comment - 2020-02-04 12:06 I just checked this in a 10.5-based branch: create table t1 (a bit(15), va bit(10) generated always as (a),pk int, primary key (pk), unique key (va)) engine=innodb; insert ignore into t1 values (0x400,0,1); Warnings: Warning 1906 The value specified for generated column 'va' in table 't1' has been ignored Warning 1264 Out of range value for column 'va' at row 1 replace into t1 (pk) values (1); An assertion fails during the REPLACE , similar to the Description. The index contents are as follows: (pk,DB_TRX_ID,DB_ROLL_PTR,a)=delete-marked(1,32,…,0x400) (delete-marked by the current transaction) (va,pk)=(0x3ff,1) We fail to find the secondary index record, because we are searching for an index entry of (va,pk)=(NULL,1) instead of (0x3ff,1). The problem seems to be that INSERT IGNORE is replacing the out-of-range bitmap value 0x400 with 0x3ff, while REPLACE is substituting NULL . I think that INSERT IGNORE must always compute indexed virtual column values in a way that is compatible with everything else. If virtual column values are materialized in an index or table, they must be evaluated consistently in all cases. Perhaps the IGNORE should be ignored altogether when indexed virtual columns exist, and the statement should return an error in this case?

Alice Sherepa added a comment - 2020-08-06 08:43

also with multi-delete

10.5 bbd70fcc43cc889e4593594ee
mysqld: /10.5/storage/innobase/row/row0upd.cc:2117: dberr_t row_upd_sec_index_entry(upd_node_t, que_thr_t): Assertion `btr_validate_index(index, 0)' failed.
200806 9:59:24 [ERROR] mysqld got signal 6 ;

linux/raise.c:51(__GI_raise)[0x7f55c8785f47]
stdlib/abort.c:81(__GI_abort)[0x7f55c87878b1]
assert/assert.c:89(__assert_fail_base)[0x7f55c877742a]
row/row0upd.cc:2118(row_upd_sec_index_entry(upd_node_t, que_thr_t))[0x564c292d3e52]
row/row0upd.cc:2247(row_upd_sec_step(upd_node_t, que_thr_t))[0x564c292d95da]
row/row0upd.cc:3024(row_upd(upd_node_t, que_thr_t))[0x564c292da0d7]
row/row0upd.cc:3139(row_upd_step(que_thr_t*))[0x564c2921fc72]
row/row0mysql.cc:1849(row_update_for_mysql(row_prebuilt_t*))[0x564c28e9af3b]
handler/ha_innodb.cc:8601(ha_innobase::delete_row(unsigned char const*))[0x564c283c4ec3]
sql/handler.cc:7253(handler::ha_delete_row(unsigned char const*))[0x564c2883611a]
sql/sql_delete.cc:277(TABLE::delete_row())[0x564c28832b07]
sql/sql_delete.cc:1330(multi_delete::send_data(List<Item>&))[0x564c27d4be93]
sql/sql_class.h:5304(select_result_sink::send_data_with_check(List<Item>&, st_select_lex_unit*, unsigned long long))[0x564c27d08c4b]
sql/sql_select.cc:21835(end_send(JOIN, st_join_table, bool))[0x564c27d0117e]
sql/sql_select.cc:20864(evaluate_join_record(JOIN, st_join_table, int))[0x564c27d00158]
sql/sql_select.cc:20680(sub_select(JOIN, st_join_table, bool))[0x564c27d0117e]
sql/sql_select.cc:20864(evaluate_join_record(JOIN, st_join_table, int))[0x564c27d00158]
sql/sql_select.cc:20680(sub_select(JOIN, st_join_table, bool))[0x564c27cfdc4f]
sql/sql_select.cc:20175(do_select(JOIN, Procedure))[0x564c27c8a8cd]
sql/sql_select.cc:4450(JOIN::exec_inner())[0x564c27c87ec6]
sql/sql_select.cc:4232(JOIN::exec())[0x564c27c8bf84]
sql/sql_select.cc:4657(mysql_select(THD, TABLE_LIST, List<Item>&, Item, unsigned int, st_order, st_order, Item, st_order, unsigned long long, select_result, st_select_lex_unit, st_select_lex))[0x564c27bc3ef5]
sql/sql_parse.cc:4837(mysql_execute_command(THD*))[0x564c27bd9121]
sql/sql_parse.cc:7994(mysql_parse(THD, char, unsigned int, Parser_state*, bool, bool))[0x564c27bafbbb]
sql/sql_parse.cc:1870(dispatch_command(enum_server_command, THD, char, unsigned int, bool, bool))[0x564c27bac439]
sql/sql_parse.cc:1348(do_command(THD*))[0x564c27fdb088]
sql/sql_connect.cc:1410(do_handle_one_connection(CONNECT*, bool))[0x564c27fda9e1]
sql/sql_connect.cc:1314(handle_one_connection)[0x564c28ca3529]
nptl/pthread_create.c:463(start_thread)[0x7f55c96826db]
x86_64/clone.S:97(clone)[0x7f55c8868a3f]

Alice Sherepa added a comment - 2020-08-06 08:43 also with multi-delete 10.5 bbd70fcc43cc889e4593594ee mysqld: /10.5/storage/innobase/row/row0upd.cc:2117: dberr_t row_upd_sec_index_entry(upd_node_t*, que_thr_t*): Assertion `btr_validate_index(index, 0)' failed. 200806 9:59:24 [ERROR] mysqld got signal 6 ; linux/raise.c:51(__GI_raise)[0x7f55c8785f47] stdlib/abort.c:81(__GI_abort)[0x7f55c87878b1] assert/assert.c:89(__assert_fail_base)[0x7f55c877742a] row/row0upd.cc:2118(row_upd_sec_index_entry(upd_node_t*, que_thr_t*))[0x564c292d3e52] row/row0upd.cc:2247(row_upd_sec_step(upd_node_t*, que_thr_t*))[0x564c292d95da] row/row0upd.cc:3024(row_upd(upd_node_t*, que_thr_t*))[0x564c292da0d7] row/row0upd.cc:3139(row_upd_step(que_thr_t*))[0x564c2921fc72] row/row0mysql.cc:1849(row_update_for_mysql(row_prebuilt_t*))[0x564c28e9af3b] handler/ha_innodb.cc:8601(ha_innobase::delete_row(unsigned char const*))[0x564c283c4ec3] sql/handler.cc:7253(handler::ha_delete_row(unsigned char const*))[0x564c2883611a] sql/sql_delete.cc:277(TABLE::delete_row())[0x564c28832b07] sql/sql_delete.cc:1330(multi_delete::send_data(List<Item>&))[0x564c27d4be93] sql/sql_class.h:5304(select_result_sink::send_data_with_check(List<Item>&, st_select_lex_unit*, unsigned long long))[0x564c27d08c4b] sql/sql_select.cc:21835(end_send(JOIN*, st_join_table*, bool))[0x564c27d0117e] sql/sql_select.cc:20864(evaluate_join_record(JOIN*, st_join_table*, int))[0x564c27d00158] sql/sql_select.cc:20680(sub_select(JOIN*, st_join_table*, bool))[0x564c27d0117e] sql/sql_select.cc:20864(evaluate_join_record(JOIN*, st_join_table*, int))[0x564c27d00158] sql/sql_select.cc:20680(sub_select(JOIN*, st_join_table*, bool))[0x564c27cfdc4f] sql/sql_select.cc:20175(do_select(JOIN*, Procedure*))[0x564c27c8a8cd] sql/sql_select.cc:4450(JOIN::exec_inner())[0x564c27c87ec6] sql/sql_select.cc:4232(JOIN::exec())[0x564c27c8bf84] sql/sql_select.cc:4657(mysql_select(THD*, TABLE_LIST*, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*))[0x564c27bc3ef5] sql/sql_parse.cc:4837(mysql_execute_command(THD*))[0x564c27bd9121] sql/sql_parse.cc:7994(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x564c27bafbbb] sql/sql_parse.cc:1870(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x564c27bac439] sql/sql_parse.cc:1348(do_command(THD*))[0x564c27fdb088] sql/sql_connect.cc:1410(do_handle_one_connection(CONNECT*, bool))[0x564c27fda9e1] sql/sql_connect.cc:1314(handle_one_connection)[0x564c28ca3529] nptl/pthread_create.c:463(start_thread)[0x7f55c96826db] x86_64/clone.S:97(clone)[0x7f55c8868a3f]

Nikita Malyavin added a comment - 2020-08-06 09:10

I think it should also fail with single DELETE IGNORE

Nikita Malyavin added a comment - 2020-08-06 09:10 I think it should also fail with single DELETE IGNORE

Nikita Malyavin added a comment - 2020-08-06 13:38 - edited

A fix for ignoring a truncation is quite fresh – it was just a year ago, and the truncation was failing before in a variety of ways.

So i think that we can just forbid REPLACEs to forcibly succeed with truncation (and other ignored by IGNORE sql modes).

Nikita Malyavin added a comment - 2020-08-06 13:38 - edited A fix for ignoring a truncation is quite fresh – it was just a year ago, and the truncation was failing before in a variety of ways. So i think that we can just forbid REPLACEs to forcibly succeed with truncation (and other ignored by IGNORE sql modes).

Nikita Malyavin added a comment - 2020-08-06 13:46

marko I think we can try not to ignore IGNOREs altogether for the sake of keeping legacy working. It is pretty possible that people use indexes with and without IGNOREs, but for example do not use REPLACEs. Or if they use Aria/Myisam

The problem in this (~~MDEV-20618~~) case is that a virtual column computation failure was erroneously treated as NULL inside innodb – some error handling was missing

Nikita Malyavin added a comment - 2020-08-06 13:46 marko I think we can try not to ignore IGNOREs altogether for the sake of keeping legacy working. It is pretty possible that people use indexes with and without IGNOREs, but for example do not use REPLACEs. Or if they use Aria/Myisam The problem in this ( MDEV-20618 ) case is that a virtual column computation failure was erroneously treated as NULL inside innodb – some error handling was missing

Marko Mäkelä added a comment - 2020-08-07 11:24

I think that INSERT IGNORE should discard rows where virtual column values cannot be evaluated. It would be analogous to INSERT IGNORE discarding rows that would violate UNIQUE KEY or PRIMARY KEY.

I think that we must always try to propagate the errors up in the call stack. The suggested fix is not doing that in all code paths.

Marko Mäkelä added a comment - 2020-08-07 11:24 I think that INSERT IGNORE should discard rows where virtual column values cannot be evaluated. It would be analogous to INSERT IGNORE discarding rows that would violate UNIQUE KEY or PRIMARY KEY . I think that we must always try to propagate the errors up in the call stack. The suggested fix is not doing that in all code paths.

Nikita Malyavin added a comment - 2020-08-10 13:11

Unfortunately, current behaviour is documented: https://mariadb.com/kb/en/insert-ignore/, so changing it will very much likely break existing workflows. It can't be done for 10.2-10.5, but we can think of changing it in 10.6+.

As for the error propagation – I completely 100% agree with both hands. But the amount of refactoring would be just amazing. Maybe we can think of it for 10.6, again, but it seems we've already run out of effort for the next release. Though we can still raise that topic up on email.

Nikita Malyavin added a comment - 2020-08-10 13:11 Unfortunately, current behaviour is documented: https://mariadb.com/kb/en/insert-ignore/ , so changing it will very much likely break existing workflows. It can't be done for 10.2-10.5, but we can think of changing it in 10.6+. As for the error propagation – I completely 100% agree with both hands. But the amount of refactoring would be just amazing. Maybe we can think of it for 10.6, again, but it seems we've already run out of effort for the next release. Though we can still raise that topic up on email.

Elena Stepanova added a comment - 2020-09-10 21:35 - edited

For a record, another failure variation fixed by the same patch. Non-debug builds were also affected.

10.2 a3d66090c
#3 <signal handler called>
#4 0x000055c41ca38db3 in row_sel_sec_rec_is_for_clust_rec (sec_rec=0x7f406deec07f "\200", sec_index=0x7f40180a39c0, clust_rec=0x7f406dee0080 "", clust_index=0x7f40180a2430, thr=0x7f4018051340) at /data/src/10.2-bug/storage/innobase/row/row0sel.cc:245
#5 0x000055c41ca3f96c in Row_sel_get_clust_rec_for_mysql::operator() (this=0x7f406d5e7940, prebuilt=0x7f4018050890, sec_index=0x7f40180a39c0, rec=0x7f406deec07f "\200", thr=0x7f4018051340, out_rec=0x7f406d5e7850, offsets=0x7f406d5e7870, offset_heap=0x7f406d5e7868, vrow=0x0, mtr=0x7f406d5e7d50) at /data/src/10.2-bug/storage/innobase/row/row0sel.cc:3569
#6 0x000055c41ca43a3d in row_search_mvcc (buf=0x7f401809f4e8 "\375", mode=PAGE_CUR_GE, prebuilt=0x7f4018050890, match_mode=1, direction=0) at /data/src/10.2-bug/storage/innobase/row/row0sel.cc:5368
#7 0x000055c41c8cfc9f in ha_innobase::index_read (this=0x7f4018192b88, buf=0x7f401809f4e8 "\375", key_ptr=0x7f401803a128 "", key_len=5, find_flag=HA_READ_KEY_EXACT) at /data/src/10.2-bug/storage/innobase/handler/ha_innodb.cc:9389
#8 0x000055c41c6d18ba in handler::index_read_map (this=0x7f4018192b88, buf=0x7f401809f4e8 "\375", key=0x7f401803a128 "", keypart_map=1, find_flag=HA_READ_KEY_EXACT) at /data/src/10.2-bug/sql/handler.h:3130
#9 0x000055c41c6c772f in handler::ha_index_read_map (this=0x7f4018192b88, buf=0x7f401809f4e8 "\375", key=0x7f401803a128 "", keypart_map=1, find_flag=HA_READ_KEY_EXACT) at /data/src/10.2-bug/sql/handler.cc:2717
#10 0x000055c41c4b1e74 in join_read_always_key (tab=0x7f40180399a8) at /data/src/10.2-bug/sql/sql_select.cc:19607
#11 0x000055c41c4b03ce in sub_select (join=0x7f4018036ba0, join_tab=0x7f40180399a8, end_of_records=false) at /data/src/10.2-bug/sql/sql_select.cc:18853
#12 0x000055c41c4af9a6 in do_select (join=0x7f4018036ba0, procedure=0x0) at /data/src/10.2-bug/sql/sql_select.cc:18400
#13 0x000055c41c489603 in JOIN::exec_inner (this=0x7f4018036ba0) at /data/src/10.2-bug/sql/sql_select.cc:3638
#14 0x000055c41c488aaa in JOIN::exec (this=0x7f4018036ba0) at /data/src/10.2-bug/sql/sql_select.cc:3433
#15 0x000055c41c489c6c in mysql_select (thd=0x7f4018000d90, tables=0x7f4018035f98, wild_num=0, fields=..., conds=0x7f4018036768, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2483292928, result=0x7f4018036ab0, unit=0x7f4018004988, select_lex=0x7f40180050c8) at /data/src/10.2-bug/sql/sql_select.cc:3833
#16 0x000055c41c47de12 in handle_select (thd=0x7f4018000d90, lex=0x7f40180048c8, result=0x7f4018036ab0, setup_tables_done_option=0) at /data/src/10.2-bug/sql/sql_select.cc:361
#17 0x000055c41c51ea35 in Sql_cmd_create_table::execute (this=0x7f40180354a8, thd=0x7f4018000d90) at /data/src/10.2-bug/sql/sql_table.cc:10944
#18 0x000055c41c447997 in mysql_execute_command (thd=0x7f4018000d90) at /data/src/10.2-bug/sql/sql_parse.cc:5964
#19 0x000055c41c44c9ad in mysql_parse (thd=0x7f4018000d90, rawbuf=0x7f40180352e8 "CREATE TABLE transforms.delete_returning_178398 SELECT field1, field2, field3, field4 FROM table_virtual WHERE field3 = 'a'", length=123, parser_state=0x7f406d5e95f0, is_com_multi=false, is_next_command=false) at /data/src/10.2-bug/sql/sql_parse.cc:7733
#20 0x000055c41c43acbc in dispatch_command (command=COM_QUERY, thd=0x7f4018000d90, packet=0x7f401802d1b1 "CREATE TABLE transforms.delete_returning_178398 SELECT field1, field2, field3, field4 FROM table_virtual WHERE field3 = 'a'", packet_length=123, is_com_multi=false, is_next_command=false) at /data/src/10.2-bug/sql/sql_parse.cc:1823
#21 0x000055c41c4397b7 in do_command (thd=0x7f4018000d90) at /data/src/10.2-bug/sql/sql_parse.cc:1377
#22 0x000055c41c59314f in do_handle_one_connection (connect=0x55c41e2d9e70) at /data/src/10.2-bug/sql/sql_connect.cc:1336
#23 0x000055c41c592eb4 in handle_one_connection (arg=0x55c41e2d9e70) at /data/src/10.2-bug/sql/sql_connect.cc:1241
#24 0x000055c41cdb9c1e in pfs_spawn_thread (arg=0x55c41e2a3fd0) at /data/src/10.2-bug/storage/perfschema/pfs.cc:1869
#25 0x00007f4073695609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#26 0x00007f407326f103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Stopped being reproducible after commit 97db6c15ea3e8.
The test case which I used for verification is below, also for a record. It seems to be deterministic on affected builds, I just did not prettify it since the problem has already been fixed.

--source include/have_innodb.inc

CREATE TABLE IF NOT EXISTS table_merge_child (field1 INTEGER NOT NULL AUTO_INCREMENT, field2 INTEGER , field3 INTEGER , field4 INTEGER, PRIMARY KEY (field1), KEY(field2)) ENGINE=InnoDB;

CREATE TABLE IF NOT EXISTS table_virtual (field1 INTEGER, field2 INTEGER AS (field1 / 2) PERSISTENT , field3 INTEGER AS (field1 * 2) VIRTUAL , field4 INTEGER AS (field1 mod 128) PERSISTENT, KEY (field2), KEY(field4)) ENGINE=InnoDB;

ALTER TABLE table_merge_child /*!100301 WAIT 2 */ ADD INDEX IF NOT EXISTS ind2 USING BTREE (field3) /*!100307, ALGORITHM=NOCOPY */, LOCK=DEFAULT;

ALTER TABLE table_virtual /*!100301 */ MODIFY IF EXISTS field1 POINT, LOCK=EXCLUSIVE;

ALTER TABLE table_virtual /*!100301 */ ADD PRIMARY KEY (field1) KEY_BLOCK_SIZE = 432, ALGORITHM=DEFAULT, LOCK=DEFAULT;

CREATE DATABASE IF NOT EXISTS transforms;

ALTER ONLINE TABLE table_virtual ADD CONSTRAINT k FOREIGN KEY f (field3) REFERENCES table_merge_child (field3) ON DELETE RESTRICT, LOCK=EXCLUSIVE;

SET SESSION FOREIGN_KEY_CHECKS = OFF;

SET SESSION tx_isolation= 'READ-UNCOMMITTED';

CREATE ALGORITHM = MERGE VIEW view3 AS SELECT field1, field2, field3, field4 FROM table_virtual;

INSERT IGNORE INTO view3 (field1, field2, field3, field4) VALUES (NULL, 236, 'b', 2), (NULL, 'bring', 8, NULL), (NULL, 238, 6, 2);

CREATE TABLE transforms.delete_returning_178398 SELECT field1, field2, field3, field4 FROM table_virtual WHERE field3 = 'a';

Elena Stepanova added a comment - 2020-09-10 21:35 - edited For a record, another failure variation fixed by the same patch. Non-debug builds were also affected. 10.2 a3d66090c #3 <signal handler called> #4 0x000055c41ca38db3 in row_sel_sec_rec_is_for_clust_rec (sec_rec=0x7f406deec07f "\200", sec_index=0x7f40180a39c0, clust_rec=0x7f406dee0080 "", clust_index=0x7f40180a2430, thr=0x7f4018051340) at /data/src/10.2-bug/storage/innobase/row/row0sel.cc:245 #5 0x000055c41ca3f96c in Row_sel_get_clust_rec_for_mysql::operator() (this=0x7f406d5e7940, prebuilt=0x7f4018050890, sec_index=0x7f40180a39c0, rec=0x7f406deec07f "\200", thr=0x7f4018051340, out_rec=0x7f406d5e7850, offsets=0x7f406d5e7870, offset_heap=0x7f406d5e7868, vrow=0x0, mtr=0x7f406d5e7d50) at /data/src/10.2-bug/storage/innobase/row/row0sel.cc:3569 #6 0x000055c41ca43a3d in row_search_mvcc (buf=0x7f401809f4e8 "\375", mode=PAGE_CUR_GE, prebuilt=0x7f4018050890, match_mode=1, direction=0) at /data/src/10.2-bug/storage/innobase/row/row0sel.cc:5368 #7 0x000055c41c8cfc9f in ha_innobase::index_read (this=0x7f4018192b88, buf=0x7f401809f4e8 "\375", key_ptr=0x7f401803a128 "", key_len=5, find_flag=HA_READ_KEY_EXACT) at /data/src/10.2-bug/storage/innobase/handler/ha_innodb.cc:9389 #8 0x000055c41c6d18ba in handler::index_read_map (this=0x7f4018192b88, buf=0x7f401809f4e8 "\375", key=0x7f401803a128 "", keypart_map=1, find_flag=HA_READ_KEY_EXACT) at /data/src/10.2-bug/sql/handler.h:3130 #9 0x000055c41c6c772f in handler::ha_index_read_map (this=0x7f4018192b88, buf=0x7f401809f4e8 "\375", key=0x7f401803a128 "", keypart_map=1, find_flag=HA_READ_KEY_EXACT) at /data/src/10.2-bug/sql/handler.cc:2717 #10 0x000055c41c4b1e74 in join_read_always_key (tab=0x7f40180399a8) at /data/src/10.2-bug/sql/sql_select.cc:19607 #11 0x000055c41c4b03ce in sub_select (join=0x7f4018036ba0, join_tab=0x7f40180399a8, end_of_records=false) at /data/src/10.2-bug/sql/sql_select.cc:18853 #12 0x000055c41c4af9a6 in do_select (join=0x7f4018036ba0, procedure=0x0) at /data/src/10.2-bug/sql/sql_select.cc:18400 #13 0x000055c41c489603 in JOIN::exec_inner (this=0x7f4018036ba0) at /data/src/10.2-bug/sql/sql_select.cc:3638 #14 0x000055c41c488aaa in JOIN::exec (this=0x7f4018036ba0) at /data/src/10.2-bug/sql/sql_select.cc:3433 #15 0x000055c41c489c6c in mysql_select (thd=0x7f4018000d90, tables=0x7f4018035f98, wild_num=0, fields=..., conds=0x7f4018036768, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2483292928, result=0x7f4018036ab0, unit=0x7f4018004988, select_lex=0x7f40180050c8) at /data/src/10.2-bug/sql/sql_select.cc:3833 #16 0x000055c41c47de12 in handle_select (thd=0x7f4018000d90, lex=0x7f40180048c8, result=0x7f4018036ab0, setup_tables_done_option=0) at /data/src/10.2-bug/sql/sql_select.cc:361 #17 0x000055c41c51ea35 in Sql_cmd_create_table::execute (this=0x7f40180354a8, thd=0x7f4018000d90) at /data/src/10.2-bug/sql/sql_table.cc:10944 #18 0x000055c41c447997 in mysql_execute_command (thd=0x7f4018000d90) at /data/src/10.2-bug/sql/sql_parse.cc:5964 #19 0x000055c41c44c9ad in mysql_parse (thd=0x7f4018000d90, rawbuf=0x7f40180352e8 "CREATE TABLE transforms.delete_returning_178398 SELECT field1, field2, field3, field4 FROM table_virtual WHERE field3 = 'a'", length=123, parser_state=0x7f406d5e95f0, is_com_multi=false, is_next_command=false) at /data/src/10.2-bug/sql/sql_parse.cc:7733 #20 0x000055c41c43acbc in dispatch_command (command=COM_QUERY, thd=0x7f4018000d90, packet=0x7f401802d1b1 "CREATE TABLE transforms.delete_returning_178398 SELECT field1, field2, field3, field4 FROM table_virtual WHERE field3 = 'a'", packet_length=123, is_com_multi=false, is_next_command=false) at /data/src/10.2-bug/sql/sql_parse.cc:1823 #21 0x000055c41c4397b7 in do_command (thd=0x7f4018000d90) at /data/src/10.2-bug/sql/sql_parse.cc:1377 #22 0x000055c41c59314f in do_handle_one_connection (connect=0x55c41e2d9e70) at /data/src/10.2-bug/sql/sql_connect.cc:1336 #23 0x000055c41c592eb4 in handle_one_connection (arg=0x55c41e2d9e70) at /data/src/10.2-bug/sql/sql_connect.cc:1241 #24 0x000055c41cdb9c1e in pfs_spawn_thread (arg=0x55c41e2a3fd0) at /data/src/10.2-bug/storage/perfschema/pfs.cc:1869 #25 0x00007f4073695609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #26 0x00007f407326f103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Stopped being reproducible after commit 97db6c15ea3e8. The test case which I used for verification is below, also for a record. It seems to be deterministic on affected builds, I just did not prettify it since the problem has already been fixed. --source include/have_innodb.inc CREATE TABLE IF NOT EXISTS table_merge_child (field1 INTEGER NOT NULL AUTO_INCREMENT, field2 INTEGER , field3 INTEGER , field4 INTEGER , PRIMARY KEY (field1), KEY (field2)) ENGINE=InnoDB; CREATE TABLE IF NOT EXISTS table_virtual (field1 INTEGER , field2 INTEGER AS (field1 / 2) PERSISTENT , field3 INTEGER AS (field1 * 2) VIRTUAL , field4 INTEGER AS (field1 mod 128) PERSISTENT, KEY (field2), KEY (field4)) ENGINE=InnoDB; ALTER TABLE table_merge_child /*!100301 WAIT 2 */ ADD INDEX IF NOT EXISTS ind2 USING BTREE (field3) /*!100307, ALGORITHM=NOCOPY */ , LOCK= DEFAULT ; ALTER TABLE table_virtual /*!100301 */ MODIFY IF EXISTS field1 POINT, LOCK=EXCLUSIVE; ALTER TABLE table_virtual /*!100301 */ ADD PRIMARY KEY (field1) KEY_BLOCK_SIZE = 432, ALGORITHM= DEFAULT , LOCK= DEFAULT ; CREATE DATABASE IF NOT EXISTS transforms; ALTER ONLINE TABLE table_virtual ADD CONSTRAINT k FOREIGN KEY f (field3) REFERENCES table_merge_child (field3) ON DELETE RESTRICT , LOCK=EXCLUSIVE; SET SESSION FOREIGN_KEY_CHECKS = OFF ; SET SESSION tx_isolation= 'READ-UNCOMMITTED' ; CREATE ALGORITHM = MERGE VIEW view3 AS SELECT field1, field2, field3, field4 FROM table_virtual; INSERT IGNORE INTO view3 (field1, field2, field3, field4) VALUES ( NULL , 236, 'b' , 2), ( NULL , 'bring' , 8, NULL ), ( NULL , 238, 6, 2); CREATE TABLE transforms.delete_returning_178398 SELECT field1, field2, field3, field4 FROM table_virtual WHERE field3 = 'a' ;

People

Assignee:: Nikita Malyavin

Reporter:: Alice Sherepa

Votes:: 0 Vote for this issue

Watchers:: 7 Start watching this issue

Dates

Created:: 2019-09-18 12:07

Updated:: 2021-08-26 11:28

Resolved:: 2020-09-01 18:49

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server