Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-20618

Assertion `btr_validate_index(index, 0, false)' failed in row_upd_sec_index_entry

Details

    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

          Bug - A problem which impairs or prevents the functions of the product. MDEV-24786 Assertion `!have_x()' failed in sux_lock<srw>::s_lock() [with srw = ssux_lock_low]

          • Major - Major loss of function.
          • Closed
          is caused by

          Task - A task that needs to be done. MDEV-5800 indexes on virtual (not materialized) columns

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed
          is duplicated by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-17834 Server crashes in row_upd_build_difference_binary on LOAD DATA into table with indexed virtual column

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-17890 Server crash on DELETE with YEAR field with truncated expr

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-20089 Unhide failed compute vcol value warning

          • Trivial - Cosmetic problem like misspelt words or misaligned text.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. 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

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. 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

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. 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

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-19771 REPLACE on table with virtual_field can cause crash in set_ok_status()

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. 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

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-20610 Assertion failed or btr_validate_index(..) in row_upd_sec_index_entry on a time_zone change

          • Major - Major loss of function.
          • Stalled

          Bug - A problem which impairs or prevents the functions of the product. MDEV-20661 Virtual fields are not recalculated on system fields value assignment

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. 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

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-22061 InnoDB: Assertion of missing row in sec index row_start upon REPLACE on a system-versioned table

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-26405 Assertion `0' failed in row_upd_sec_index_entry

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            View 6 older comments
            nikitamalyavin Nikita Malyavin added a comment - - 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).

            nikitamalyavin Nikita Malyavin added a comment - - 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).
            nikitamalyavin Nikita Malyavin added a comment -

            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

            nikitamalyavin Nikita Malyavin added a comment - 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 Marko Mäkelä added a comment -

            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 Marko Mäkelä added a comment - 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.
            nikitamalyavin Nikita Malyavin added a comment -

            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.

            nikitamalyavin Nikita Malyavin added a comment - 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.
            elenst Elena Stepanova added a comment - - 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';

            elenst Elena Stepanova added a comment - - 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

              nikitamalyavin Nikita Malyavin
              alice Alice Sherepa
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

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