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

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Critical
Resolution: Fixed
Affects Version/s: 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL)
Fix Version/s: 10.2.40, 10.3.31, 10.4.21, 10.5.12, 10.6.4
Component/s: Storage Engine - InnoDB, Virtual Columns
Labels:

Description

Actual description

Changing support_virtual_index to 1 in mysql-test/suite/gcol/t/gcol_ins_upd_innodb.test leads to a server crash.

The root cause test is following:

DROP TABLE IF EXISTS t;

CREATE TABLE t (

  a INT,

  b YEAR GENERATED ALWAYS AS ('a') VIRTUAL,

  c YEAR GENERATED ALWAYS AS ('aaaa') VIRTUAL,

  b1 YEAR GENERATED ALWAYS AS ('a') STORED,

  c1 YEAR GENERATED ALWAYS AS ('aaaa') STORED,

  UNIQUE(b),

  UNIQUE(b1)

) ENGINE=InnoDB;

INSERT IGNORE INTO t VALUES();

SELECT b from t;

SELECT b1 from t;

SELECT * from t;

DELETE FROM t;

Stack trace:

#0  0x00007ffff76f357f in raise () from /lib64/libc.so.6

#1  0x00007ffff76dd895 in abort () from /lib64/libc.so.6

#2  0x00007ffff76dd769 in __assert_fail_base.cold.0 () from /lib64/libc.so.6

#3  0x00007ffff76eba26 in __assert_fail () from /lib64/libc.so.6

#4  0x0000000000eff8b8 in row_upd_sec_index_entry (node=0x7fff680704d8, thr=0x7fff68074f88)

    at /home/bar/maria-git/server.10.4/storage/innobase/row/row0upd.cc:2429

#5  0x0000000000efff2a in row_upd_sec_step (node=0x7fff680704d8, thr=0x7fff68074f88)

    at /home/bar/maria-git/server.10.4/storage/innobase/row/row0upd.cc:2543

#6  0x0000000000f02642 in row_upd (node=0x7fff680704d8, thr=0x7fff68074f88)

    at /home/bar/maria-git/server.10.4/storage/innobase/row/row0upd.cc:3319

#7  0x0000000000f029a9 in row_upd_step (thr=0x7fff68074f88)

    at /home/bar/maria-git/server.10.4/storage/innobase/row/row0upd.cc:3434

#8  0x0000000000eb6458 in row_update_for_mysql (prebuilt=0x7fff6806f918)

    at /home/bar/maria-git/server.10.4/storage/innobase/row/row0mysql.cc:1889

#9  0x0000000000d60bd8 in ha_innobase::delete_row (this=0x7fff680659f8,

    record=0x7fff6806e970 <incomplete sequence \313>)

    at /home/bar/maria-git/server.10.4/storage/innobase/handler/ha_innodb.cc:8970

#10 0x0000000000b4bfb2 in handler::ha_delete_row (this=0x7fff680659f8,

    buf=0x7fff6806e970 <incomplete sequence \313>)

    at /home/bar/maria-git/server.10.4/sql/handler.cc:6790

#11 0x0000000000ce6581 in TABLE::delete_row (this=0x7fff68064b90)

    at /home/bar/maria-git/server.10.4/sql/sql_delete.cc:297

#12 0x0000000000ce3603 in mysql_delete (thd=0x7fff68000d60, table_list=0x7fff68014230,

    conds=0x0, order_list=0x7fff68005710, limit=18446744073709551615, options=0,

    result=0x0) at /home/bar/maria-git/server.10.4/sql/sql_delete.cc:834

#13 0x00000000008220ad in mysql_execute_command (thd=0x7fff68000d60)

    at /home/bar/maria-git/server.10.4/sql/sql_parse.cc:4727

#14 0x000000000082cd07 in mysql_parse (thd=0x7fff68000d60,

    rawbuf=0x7fff68014168 "DELETE FROM t", length=13, parser_state=0x7ffff41d7000,

    is_com_multi=false, is_next_command=false)

    at /home/bar/maria-git/server.10.4/sql/sql_parse.cc:7908

Original description

Note: ~~MDEV-14134~~ is marked as a duplicate of ~~MDEV-15114~~ and the latter is closed, so I'm filing a new one.

--source include/have_innodb.inc

CREATE TABLE t1 (

  pk BIGINT AUTO_INCREMENT,

  b BIT(15),

  v BIT(10) AS (b) VIRTUAL,

  PRIMARY KEY(pk),

  UNIQUE(v)

) ENGINE=InnoDB;

INSERT IGNORE INTO t1 (b) VALUES (b'101110001110100'),(b'011101');

SELECT pk, b FROM t1 INTO OUTFILE 'load.data';

LOAD DATA INFILE 'load.data' REPLACE INTO TABLE t1 (pk, b);

# Cleanup

DROP TABLE t1;

--let $datadir= `SELECT @@datadir`

--remove_file $datadir/test/load.data

10.2 f2c7972a debug
2018-12-03 18:50:43 140185924466432 [ERROR] InnoDB: Record in index `v` of table `test`.`t1` was not found on update: TUPLE (info_bits=0, 2 fields): {NULL,[8] (0x8000000000000001)} at: COMPACT RECORD(info_bits=0, 1 fields): {[8]infimum (0x696E66696D756D00)}
mysqld: /data/src/10.2/storage/innobase/row/row0upd.cc:2436: dberr_t row_upd_sec_index_entry(upd_node_t, que_thr_t): Assertion `0' failed.
181203 18:50:43 [ERROR] mysqld got signal 6 ;

#7 0x00007f583467aee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8 0x0000562b2a093991 in row_upd_sec_index_entry (node=0x7f57c406cbc0, thr=0x7f57c408fd38) at /data/src/10.2/storage/innobase/row/row0upd.cc:2436
#9 0x0000562b2a094007 in row_upd_sec_step (node=0x7f57c406cbc0, thr=0x7f57c408fd38) at /data/src/10.2/storage/innobase/row/row0upd.cc:2549
#10 0x0000562b2a096288 in row_upd (node=0x7f57c406cbc0, thr=0x7f57c408fd38) at /data/src/10.2/storage/innobase/row/row0upd.cc:3308
#11 0x0000562b2a0965d9 in row_upd_step (thr=0x7f57c408fd38) at /data/src/10.2/storage/innobase/row/row0upd.cc:3425
#12 0x0000562b2a03cc7d in row_update_for_mysql (prebuilt=0x7f57c406c068) at /data/src/10.2/storage/innobase/row/row0mysql.cc:1830
#13 0x0000562b29f030c1 in ha_innobase::delete_row (this=0x7f57c4009d28, record=0x7f57c400b750 "\241\001") at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:9098
#14 0x0000562b29bf711a in handler::ha_delete_row (this=0x7f57c4009d28, buf=0x7f57c400b750 "\241\001") at /data/src/10.2/sql/handler.cc:6021
#15 0x0000562b2994c547 in write_record (thd=0x7f57c4000b00, table=0x7f57c4009120, info=0x7f582c2e4040) at /data/src/10.2/sql/sql_insert.cc:1893
#16 0x0000562b29d91a8c in read_sep_field (thd=0x7f57c4000b00, info=..., table_list=0x7f57c40125d0, fields_vars=..., set_fields=..., set_values=..., read_info=..., enclosed=..., skip_lines=0, ignore_check_option_errors=false) at /data/src/10.2/sql/sql_load.cc:1256
#17 0x0000562b29d8fc24 in mysql_load (thd=0x7f57c4000b00, ex=0x7f57c4012548, table_list=0x7f57c40125d0, fields_vars=..., set_fields=..., set_values=..., handle_duplicates=DUP_REPLACE, ignore=false, read_file_from_client=false) at /data/src/10.2/sql/sql_load.cc:649
#18 0x0000562b2997345c in mysql_execute_command (thd=0x7f57c4000b00) at /data/src/10.2/sql/sql_parse.cc:4834
#19 0x0000562b2997d1bd in mysql_parse (thd=0x7f57c4000b00, rawbuf=0x7f57c4012448 "LOAD DATA INFILE 'load.data' REPLACE INTO TABLE t1 (pk, b)", length=58, parser_state=0x7f582c2e5200, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:8013
#20 0x0000562b2996aaf5 in dispatch_command (command=COM_QUERY, thd=0x7f57c4000b00, packet=0x7f57c4095ec1 "LOAD DATA INFILE 'load.data' REPLACE INTO TABLE t1 (pk, b)", packet_length=58, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1824
#21 0x0000562b29969458 in do_command (thd=0x7f57c4000b00) at /data/src/10.2/sql/sql_parse.cc:1378
#22 0x0000562b29abbbc9 in do_handle_one_connection (connect=0x562b2c34e0c0) at /data/src/10.2/sql/sql_connect.cc:1335
#23 0x0000562b29abb956 in handle_one_connection (arg=0x562b2c34e0c0) at /data/src/10.2/sql/sql_connect.cc:1241
#24 0x0000562b29ee15ee in pfs_spawn_thread (arg=0x562b2c299570) at /data/src/10.2/storage/perfschema/pfs.cc:1862
#25 0x00007f5836136494 in start_thread (arg=0x7f582c2e6700) at pthread_create.c:333
#26 0x00007f583473793f in clone () from /lib/x86_64-linux-gnu/libc.so.6

10.2 f2c7972a non-debug
2018-12-03 18:54:20 140039024932608 [ERROR] InnoDB: Record in index `v` of table `test`.`t1` was not found on update: TUPLE (info_bits=0, 2 fields): {NULL,[8] (0x8000000000000001)} at: COMPACT RECORD(info_bits=0, 1 fields): {[8]infimum (0x696E66696D756D00)}
181203 18:54:20 [ERROR] mysqld got signal 11 ;

#2 <signal handler called>
#3 row_upd_build_difference_binary (index=0x7f5cfc0b9180, entry=entry@entry=0x7f5cfc0bd390, rec=<optimized out>, offsets=<optimized out>, offsets@entry=0x0, no_sys=no_sys@entry=true, trx=<optimized out>, heap=0x7f5cfc0b7b20, mysql_table=0x7f5cfc0bbc98) at /data/src/10.2/storage/innobase/row/row0upd.cc:1165
#4 0x000056283a9293d3 in row_ins_clust_index_entry_by_modify (mtr=0x7f5d6055b130, thr=<optimized out>, entry=0x7f5cfc0bd390, heap=0x7f5cfc0b7b20, offsets_heap=0x7f5d6055a5d0, offsets=0x7f5d6055a5d8, mode=2, flags=0, pcur=0x7f5d6055a630) at /data/src/10.2/storage/innobase/row/row0ins.cc:352
#5 row_ins_clust_index_entry_low (flags=<optimized out>, mode=2, index=0x7f5cfc0b9180, n_uniq=<optimized out>, entry=<optimized out>, n_ext=<optimized out>, thr=0x7f5cfc0b6868, dup_chk_only=false) at /data/src/10.2/storage/innobase/row/row0ins.cc:2650
#6 0x000056283a92a02b in row_ins_clust_index_entry (index=0x7f5cfc0b9180, entry=0x7f5cfc0bd390, thr=0x7f5cfc0b6868, n_ext=0, dup_chk_only=2, dup_chk_only@entry=false) at /data/src/10.2/storage/innobase/row/row0ins.cc:3170
#7 0x000056283a92a731 in row_ins_index_entry (thr=0x7f5cfc0b6868, entry=<optimized out>, index=0x7f5cfc0b9180) at /data/src/10.2/storage/innobase/row/row0ins.cc:3292
#8 row_ins_index_entry_step (thr=0x7f5cfc0b6868, node=<optimized out>) at /data/src/10.2/storage/innobase/row/row0ins.cc:3442
#9 row_ins (thr=<optimized out>, node=<optimized out>) at /data/src/10.2/storage/innobase/row/row0ins.cc:3585
#10 row_ins_step (thr=thr@entry=0x7f5cfc0b6868) at /data/src/10.2/storage/innobase/row/row0ins.cc:3811
#11 0x000056283a939468 in row_insert_for_mysql (mysql_rec=mysql_rec@entry=0x7f5cfc0b9998 "\371\001", prebuilt=0x7f5cfc0b6070) at /data/src/10.2/storage/innobase/row/row0mysql.cc:1413
#12 0x000056283a889061 in ha_innobase::write_row (this=0x7f5cfc0bc830, record=0x7f5cfc0b9998 "\371\001") at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:8224
#13 0x000056283a66957a in handler::ha_write_row (this=0x7f5cfc0bc830, buf=0x7f5cfc0b9998 "\371\001") at /data/src/10.2/sql/handler.cc:5961
#14 0x000056283a4af694 in write_record (thd=thd@entry=0x7f5cfc0009a8, table=table@entry=0x7f5cfc0bbc98, info=info@entry=0x7f5d6055c630) at /data/src/10.2/sql/sql_insert.cc:1655
#15 0x000056283a794ec4 in read_sep_field (ignore_check_option_errors=<optimized out>, skip_lines=<optimized out>, enclosed=..., read_info=..., set_values=..., set_fields=..., fields_vars=..., table_list=0x7f5cfc00f218, info=..., thd=0x7f5cfc0009a8) at /data/src/10.2/sql/sql_load.cc:1256
#16 mysql_load (thd=<optimized out>, ex=<optimized out>, table_list=0x7f5cfc00f218, fields_vars=..., set_fields=..., set_values=..., handle_duplicates=DUP_REPLACE, ignore=<optimized out>, read_file_from_client=false) at /data/src/10.2/sql/sql_load.cc:649
#17 0x000056283a4ce991 in mysql_execute_command (thd=0x7f5cfc0009a8) at /data/src/10.2/sql/sql_parse.cc:4834
#18 0x000056283a4d230a in mysql_parse (thd=0x7f5cfc0009a8, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>, is_com_multi=<optimized out>, is_next_command=<optimized out>) at /data/src/10.2/sql/sql_parse.cc:8013
#19 0x000056283a4d5e84 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x7f5cfc0009a8, packet=packet@entry=0x7f5cfc006ce9 "LOAD DATA INFILE 'load.data' REPLACE INTO TABLE t1 (pk, b)", packet_length=packet_length@entry=58, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/src/10.2/sql/sql_parse.cc:1824
#20 0x000056283a4d68b9 in do_command (thd=0x7f5cfc0009a8) at /data/src/10.2/sql/sql_parse.cc:1378
#21 0x000056283a59f7c4 in do_handle_one_connection (connect=connect@entry=0x56283d977798) at /data/src/10.2/sql/sql_connect.cc:1335
#22 0x000056283a59f964 in handle_one_connection (arg=arg@entry=0x56283d977798) at /data/src/10.2/sql/sql_connect.cc:1241
#23 0x000056283a8638a4 in pfs_spawn_thread (arg=0x56283d93a078) at /data/src/10.2/storage/perfschema/pfs.cc:1862
#24 0x00007f5d71bc6494 in start_thread (arg=0x7f5d6055f700) at pthread_create.c:333
#25 0x00007f5d701c793f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Attachments

Issue Links

duplicates

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

Closed

relates to

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-19486 Server crashes in row_upd or row_upd_del_mark_clust_rec on REPLACE into a versioned table

Closed

MDEV-26453 Assertion `0' failed in row_upd_sec_index_entry & corruption

Closed

MDEV-14134 gcol.innodb_virtual_debug sporadically failed in buildbot, row0upd.cc:2427: dberr_t row_upd_sec_index_entry(upd_node_t*, que_thr_t*): Assertion `0' failed

Closed

MDEV-15114 ASAN heap-use-after-free in mem_heap_dup or dfield_data_is_binary_equal

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-20152 Generated column's index not updated from RBR events (both Galera and async replication)

Open

MDEV-27744 LPAD in vcol created in ORACLE mode makes table corrupted in non-ORACLE

Closed

(4 relates to)

Activity

Ascending order - Click to sort in descending order

View 10 older comments

Nikita Malyavin added a comment - 2021-06-20 18:28 - edited

This goes deeper in the year truncation cripples. Even for MyISAM the behavior is undefined:

CREATE TABLE t (

a INT,

b YEAR GENERATED ALWAYS AS ('a') VIRTUAL,

c YEAR GENERATED ALWAYS AS ('aaaa') VIRTUAL,

b1 YEAR GENERATED ALWAYS AS ('a') STORED,

c1 YEAR GENERATED ALWAYS AS ('aaaa') STORED,

UNIQUE(b),

UNIQUE(b1)

) ENGINE=MYISAM;

INSERT IGNORE INTO t VALUES();

Warnings:

Warning	1366	Incorrect integer value: 'a' for column `test`.`t`.`b` at row 1

Warning	1366	Incorrect integer value: 'a' for column `test`.`t`.`b1` at row 1

Warning	1366	Incorrect integer value: 'aaaa' for column `test`.`t`.`c1` at row 1

SELECT b from t;

SELECT b1 from t;

b1

SELECT b from t;

SELECT b, b1 from t;

b	b1

2000	0000

SELECT * from t;

a	b	c	b1	c1

NULL	2000	0000	0000	0000

DELETE FROM t;

DROP TABLE t;

INSERT IGNORE calculates the value as 0000, but SELECT calculates it as 2000.

The difference is dictated by THD::count_cuted_fields parameter value, which is set to CHECK_FIELD_WARN for INSERT IGNORE, and to CHECK_FIELD_IGNORE (default) in most other statements.

Innodb requires the virtual index record be always accessible when calculated, while Aria/MyISAM are careless. My side guess is MyISAM may even store junk secondary index records in such cases.

With this simple patch
(note that TABLE::update_virtual_field is only called by InnoDB, and by MyISAM's repair)

--- a/sql/table.cc

+++ b/sql/table.cc

@@ -7798,8 +7798,11 @@ int TABLE::update_virtual_field(Field *vf)

   in_use->push_internal_handler(&count_errors);

   in_use->set_n_backup_active_arena(expr_arena, &backup_arena);

   bitmap_clear_all(&tmp_set);

+  enum_check_fields check_fields= in_use->count_cuted_fields;

+  in_use->count_cuted_fields= CHECK_FIELD_WARN;

   vf->vcol_info->expr->walk(&Item::update_vcol_processor, 0, &tmp_set);

   vf->vcol_info->expr->save_in_field(vf, 0);

+  in_use->count_cuted_fields= check_fields;

   in_use->restore_active_arena(expr_arena, &backup_arena);

   in_use->pop_internal_handler();

   DBUG_RETURN(count_errors.errors);

The crash gets fixed, but the results may vary even depending on the optimizer path (depending on whether the column value was calculated in the runtime side (sql_select.cc, etc) or inside the engine). Therefore, even two identical SELECT calls may return different results for a single record.

With the patch above:

CREATE TABLE t (

a INT,

b YEAR GENERATED ALWAYS AS ('a') VIRTUAL,

c YEAR GENERATED ALWAYS AS ('aaaa') VIRTUAL,

b1 YEAR GENERATED ALWAYS AS ('a') STORED,

c1 YEAR GENERATED ALWAYS AS ('aaaa') STORED,

UNIQUE(b),

UNIQUE(b1)

) ENGINE=InnoDB;

INSERT IGNORE INTO t VALUES();

Warnings:

Warning	1366	Incorrect integer value: 'a' for column `test`.`t`.`b` at row 1

Warning	1366	Incorrect integer value: 'a' for column `test`.`t`.`b1` at row 1

Warning	1366	Incorrect integer value: 'aaaa' for column `test`.`t`.`c1` at row 1

SELECT b from t;

SELECT b1 from t;

b1

SELECT b from t;

SELECT b, b1 from t;

b	b1

2000	0000

SELECT * from t;

a	b	c	b1	c1

NULL	2000	0000	0000	0000

DELETE FROM t;

Warnings:

Warning	1366	Incorrect integer value: 'a' for column `test`.`t`.`b` at row 1

Due to our legacy treatments, we would prefer to preserve current behavior, however changing Field_year behavior a bit:

diff --git a/sql/field.cc b/sql/field.cc

--- a/sql/field.cc	(revision cd1a195b22d2dac248228b6b7ecbd0a54997ecf7)

+++ b/sql/field.cc	(date 1624212410457)

@@ -6384,7 +6384,7 @@

     set_warning(ER_WARN_DATA_OUT_OF_RANGE, 1);

     return 1;

-  if (get_thd()->count_cuted_fields &&

+  if (get_thd()->count_cuted_fields == CHECK_FIELD_ERROR_FOR_NULL &&

       (error= check_int(cs, from, len, end, error)))

     if (error == 1)  /* empty or incorrect string */

produces charming results:

CREATE TABLE t (

a INT,

b YEAR GENERATED ALWAYS AS ('a') VIRTUAL,

c YEAR GENERATED ALWAYS AS ('aaaa') VIRTUAL,

b1 YEAR GENERATED ALWAYS AS ('a') STORED,

c1 YEAR GENERATED ALWAYS AS ('aaaa') STORED,

UNIQUE(b),

UNIQUE(b1)

) ENGINE=InnoDB;

INSERT IGNORE INTO t VALUES();

SELECT b from t;

SELECT b1 from t;

b1

SELECT b from t;

SELECT b, b1 from t;

b	b1

2000	2000

SELECT * from t;

a	b	c	b1	c1

NULL	2000	0000	2000	0000

DELETE FROM t;

DROP TABLE t;

If the test runs will produce no significant changes, I would propose the second solution, which will change the behaviour slightly for 10.2+.

serg, sanja what's your opinion?

Nikita Malyavin added a comment - 2021-06-20 18:28 - edited This goes deeper in the year truncation cripples. Even for MyISAM the behavior is undefined: CREATE TABLE t ( a INT , b YEAR GENERATED ALWAYS AS ( 'a' ) VIRTUAL, c YEAR GENERATED ALWAYS AS ( 'aaaa' ) VIRTUAL, b1 YEAR GENERATED ALWAYS AS ( 'a' ) STORED, c1 YEAR GENERATED ALWAYS AS ( 'aaaa' ) STORED, UNIQUE (b), UNIQUE (b1) ) ENGINE=MYISAM; INSERT IGNORE INTO t VALUES (); Warnings: Warning 1366 Incorrect integer value: 'a' for column `test`.`t`.`b` at row 1 Warning 1366 Incorrect integer value: 'a' for column `test`.`t`.`b1` at row 1 Warning 1366 Incorrect integer value: 'aaaa' for column `test`.`t`.`c1` at row 1 SELECT b from t; b 2000 SELECT b1 from t; b1 0000 SELECT b from t; b 2000 SELECT b, b1 from t; b b1 2000 0000 SELECT * from t; a b c b1 c1 NULL 2000 0000 0000 0000 DELETE FROM t; DROP TABLE t; INSERT IGNORE calculates the value as 0000, but SELECT calculates it as 2000. The difference is dictated by THD::count_cuted_fields parameter value, which is set to CHECK_FIELD_WARN for INSERT IGNORE, and to CHECK_FIELD_IGNORE (default) in most other statements. Innodb requires the virtual index record be always accessible when calculated, while Aria/MyISAM are careless. My side guess is MyISAM may even store junk secondary index records in such cases. With this simple patch (note that TABLE::update_virtual_field is only called by InnoDB, and by MyISAM's repair) --- a/sql/table.cc +++ b/sql/table.cc @@ -7798,8 +7798,11 @@ int TABLE::update_virtual_field(Field *vf) in_use->push_internal_handler(&count_errors); in_use->set_n_backup_active_arena(expr_arena, &backup_arena); bitmap_clear_all(&tmp_set); + enum_check_fields check_fields= in_use->count_cuted_fields; + in_use->count_cuted_fields= CHECK_FIELD_WARN; vf->vcol_info->expr->walk(&Item::update_vcol_processor, 0, &tmp_set); vf->vcol_info->expr->save_in_field(vf, 0); + in_use->count_cuted_fields= check_fields; in_use->restore_active_arena(expr_arena, &backup_arena); in_use->pop_internal_handler(); DBUG_RETURN(count_errors.errors); The crash gets fixed, but the results may vary even depending on the optimizer path (depending on whether the column value was calculated in the runtime side (sql_select.cc, etc) or inside the engine). Therefore, even two identical SELECT calls may return different results for a single record. With the patch above: CREATE TABLE t ( a INT , b YEAR GENERATED ALWAYS AS ( 'a' ) VIRTUAL, c YEAR GENERATED ALWAYS AS ( 'aaaa' ) VIRTUAL, b1 YEAR GENERATED ALWAYS AS ( 'a' ) STORED, c1 YEAR GENERATED ALWAYS AS ( 'aaaa' ) STORED, UNIQUE (b), UNIQUE (b1) ) ENGINE=InnoDB; INSERT IGNORE INTO t VALUES (); Warnings: Warning 1366 Incorrect integer value: 'a' for column `test`.`t`.`b` at row 1 Warning 1366 Incorrect integer value: 'a' for column `test`.`t`.`b1` at row 1 Warning 1366 Incorrect integer value: 'aaaa' for column `test`.`t`.`c1` at row 1 SELECT b from t; b 0000 SELECT b1 from t; b1 0000 SELECT b from t; b 0000 SELECT b, b1 from t; b b1 2000 0000 SELECT * from t; a b c b1 c1 NULL 2000 0000 0000 0000 DELETE FROM t; Warnings: Warning 1366 Incorrect integer value: 'a' for column `test`.`t`.`b` at row 1 Due to our legacy treatments, we would prefer to preserve current behavior, however changing Field_year behavior a bit: diff --git a/sql/field.cc b/sql/field.cc --- a/sql/field.cc (revision cd1a195b22d2dac248228b6b7ecbd0a54997ecf7) +++ b/sql/field.cc (date 1624212410457) @@ -6384,7 +6384,7 @@ set_warning(ER_WARN_DATA_OUT_OF_RANGE, 1); return 1; } - if (get_thd()->count_cuted_fields && + if (get_thd()->count_cuted_fields == CHECK_FIELD_ERROR_FOR_NULL && (error= check_int(cs, from, len, end, error))) { if (error == 1) /* empty or incorrect string */ produces charming results: CREATE TABLE t ( a INT , b YEAR GENERATED ALWAYS AS ( 'a' ) VIRTUAL, c YEAR GENERATED ALWAYS AS ( 'aaaa' ) VIRTUAL, b1 YEAR GENERATED ALWAYS AS ( 'a' ) STORED, c1 YEAR GENERATED ALWAYS AS ( 'aaaa' ) STORED, UNIQUE (b), UNIQUE (b1) ) ENGINE=InnoDB; INSERT IGNORE INTO t VALUES (); SELECT b from t; b 2000 SELECT b1 from t; b1 2000 SELECT b from t; b 2000 SELECT b, b1 from t; b b1 2000 2000 SELECT * from t; a b c b1 c1 NULL 2000 0000 2000 0000 DELETE FROM t; DROP TABLE t; If the test runs will produce no significant changes, I would propose the second solution, which will change the behaviour slightly for 10.2+. serg , sanja what's your opinion?

Nikita Malyavin added a comment - 2021-06-20 18:52

main.type_year and main.type_date have meaningfully failed:

--- /home/nik/mariadb/mysql-test/r/type_date.result	2021-06-15 22:28:31.819710775 +0300

+++ /home/nik/mariadb/mysql-test/r/type_date.reject	2021-06-20 21:43:28.526054857 +0300

@@ -107,11 +107,9 @@

 DROP TABLE t1, t2, t3;

 CREATE TABLE t1 (y YEAR);

 INSERT IGNORE INTO t1 VALUES ('abc');

-Warnings:

-Warning	1366	Incorrect integer value: 'abc' for column `test`.`t1`.`y` at row 1

 SELECT * FROM t1;

-0000

+2000

 DROP TABLE t1;

 create table t1(start_date date, end_date date);

 insert into t1 values ('2000-01-01','2000-01-02');

--- /home/nik/mariadb/mysql-test/r/type_year.result	2021-06-15 22:28:31.826377462 +0300

+++ /home/nik/mariadb/mysql-test/r/type_year.reject	2021-06-20 21:41:33.795394375 +0300

@@ -43,8 +43,6 @@

 create table t1(a year);

 insert into t1 values (2000.5), ('2000.5'), ('2001a'), ('2.001E3');

-Warnings:

-Warning	1265	Data truncated for column 'a' at row 3

 select * from t1;

Of course, gcol.gcol_ins_upd_myisam had failed too, but that's relatively insignificant, and reflects type_date results

Nikita Malyavin added a comment - 2021-06-20 18:52 main.type_year and main.type_date have meaningfully failed: --- /home/nik/mariadb/mysql-test/r/type_date.result 2021-06-15 22:28:31.819710775 +0300 +++ /home/nik/mariadb/mysql-test/r/type_date.reject 2021-06-20 21:43:28.526054857 +0300 @@ -107,11 +107,9 @@ DROP TABLE t1, t2, t3; CREATE TABLE t1 (y YEAR ); INSERT IGNORE INTO t1 VALUES ( 'abc' ); -Warnings: -Warning 1366 Incorrect integer value: 'abc' for column `test`.`t1`.`y` at row 1 SELECT * FROM t1; y -0000 +2000 DROP TABLE t1; create table t1(start_date date , end_date date ); insert into t1 values ( '2000-01-01' , '2000-01-02' ); --- /home/nik/mariadb/mysql-test/r/type_year.result 2021-06-15 22:28:31.826377462 +0300 +++ /home/nik/mariadb/mysql-test/r/type_year.reject 2021-06-20 21:41:33.795394375 +0300 @@ -43,8 +43,6 @@ # create table t1(a year ); insert into t1 values (2000.5), ( '2000.5' ), ( '2001a' ), ( '2.001E3' ); -Warnings: -Warning 1265 Data truncated for column 'a' at row 3 select * from t1; a 2001 Of course, gcol.gcol_ins_upd_myisam had failed too, but that's relatively insignificant, and reflects type_date results

Nikita Malyavin added a comment - 2021-06-20 19:17

Warnings should not be removed. Thereby, a little bit more careful patch does well:

diff --git a/sql/field.cc b/sql/field.cc

--- a/sql/field.cc	(revision cd1a195b22d2dac248228b6b7ecbd0a54997ecf7)

+++ b/sql/field.cc	(date 1624216210532)

@@ -6384,10 +6384,11 @@

     set_warning(ER_WARN_DATA_OUT_OF_RANGE, 1);

     return 1;

-  if (get_thd()->count_cuted_fields &&

+  if (get_thd()->count_cuted_fields != CHECK_FIELD_IGNORE &&

       (error= check_int(cs, from, len, end, error)))

-    if (error == 1)  /* empty or incorrect string */

+    if (unlikely(error == 1) &&      /* empty or incorrect string */

+        get_thd()->count_cuted_fields == CHECK_FIELD_ERROR_FOR_NULL)

       *ptr= 0;

       return 1;

Only main.type_date differs then:

--- /home/nik/mariadb/mysql-test/r/type_date.result	2021-06-15 22:28:31.819710775 +0300

+++ /home/nik/mariadb/mysql-test/r/type_date.reject	2021-06-20 22:11:55.703674542 +0300

@@ -111,7 +111,7 @@

 Warning	1366	Incorrect integer value: 'abc' for column `test`.`t1`.`y` at row 1

 SELECT * FROM t1;

-0000

+2000

 DROP TABLE t1;

 create table t1(start_date date, end_date date);

 insert into t1 values ('2000-01-01','2000-01-02');

And type_year passes.

Nikita Malyavin added a comment - 2021-06-20 19:17 Warnings should not be removed. Thereby, a little bit more careful patch does well: diff --git a/sql/field.cc b/sql/field.cc --- a/sql/field.cc (revision cd1a195b22d2dac248228b6b7ecbd0a54997ecf7) +++ b/sql/field.cc (date 1624216210532) @@ -6384,10 +6384,11 @@ set_warning(ER_WARN_DATA_OUT_OF_RANGE, 1); return 1; } - if (get_thd()->count_cuted_fields && + if (get_thd()->count_cuted_fields != CHECK_FIELD_IGNORE && (error= check_int(cs, from, len, end, error))) { - if (error == 1) /* empty or incorrect string */ + if (unlikely(error == 1) && /* empty or incorrect string */ + get_thd()->count_cuted_fields == CHECK_FIELD_ERROR_FOR_NULL) { *ptr= 0; return 1; Only main.type_date differs then: --- /home/nik/mariadb/mysql-test/r/type_date.result 2021-06-15 22:28:31.819710775 +0300 +++ /home/nik/mariadb/mysql-test/r/type_date.reject 2021-06-20 22:11:55.703674542 +0300 @@ -111,7 +111,7 @@ Warning 1366 Incorrect integer value: 'abc' for column `test`.`t1`.`y` at row 1 SELECT * FROM t1; y -0000 +2000 DROP TABLE t1; create table t1(start_date date , end_date date ); insert into t1 values ( '2000-01-01' , '2000-01-02' ); And type_year passes.

Nikita Malyavin added a comment - 2021-06-21 01:10

Turns out that setting a value to 0000 was a previous decision: see Bug #6067 and commit [ 6162c4a6eb|https://github.com/MariaDB/server/commit/6162c4a6eb22b413a477bb6b9b0f08ec9b98a193]

So I think we should stay consistent with that decision. This also means that current SELECT output for myisam is incorrect in gcol.gcol_ins_upd_myisam

The patch is ready for a review: https://github.com/MariaDB/server/commit/8185a2889f21e4782eeb8a09d386d4a4e661cc08

Nikita Malyavin added a comment - 2021-06-21 01:10 Turns out that setting a value to 0000 was a previous decision: see Bug #6067 and commit [ 6162c4a6eb|https://github.com/MariaDB/server/commit/6162c4a6eb22b413a477bb6b9b0f08ec9b98a193] So I think we should stay consistent with that decision. This also means that current SELECT output for myisam is incorrect in gcol.gcol_ins_upd_myisam The patch is ready for a review: https://github.com/MariaDB/server/commit/8185a2889f21e4782eeb8a09d386d4a4e661cc08

Roel Van de Paar added a comment - 2021-08-20 20:51 - edited

Various testcases in this bug still fail including the following testcase from Elena.

CREATE TABLE t1 (pk INT AUTO_INCREMENT PRIMARY KEY, b TEXT, i INT, UNIQUE(i), UNIQUE(b)) ENGINE=InnoDB;

INSERT INTO t1 (b,i) VALUES ('foo',1);

SET STATEMENT time_zone= '-07:50' FOR ALTER TABLE t1 ADD SYSTEM VERSIONING;

REPLACE INTO t1 (b,i) VALUES ('foo',1);

10.7.0 52505bf20de0ce77a5c0b0a74af021051987bb0d (Debug)
mysqld: /test/10.7_dbg/storage/innobase/row/row0upd.cc:2051: dberr_t row_upd_sec_index_entry(upd_node_t, que_thr_t): Assertion `0' failed.

10.7.0 52505bf20de0ce77a5c0b0a74af021051987bb0d (Debug)
Core was generated by `/test/MD160821-mariadb-10.7.0-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 0x149ffc91b700 (LWP 473547))]
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x0000149fff4d9859 in __GI_abort () at abort.c:79
#2 0x0000149fff4d9729 in __assert_fail_base (fmt=0x149fff66f588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x562312ed5b6b "0", file=0x562312fac310 "/test/10.7_dbg/storage/innobase/row/row0upd.cc", line=2051, function=<optimized out>) at assert.c:92
#3 0x0000149fff4eaf36 in __GI___assert_fail (assertion=assertion@entry=0x562312ed5b6b "0", file=file@entry=0x562312fac310 "/test/10.7_dbg/storage/innobase/row/row0upd.cc", line=line@entry=2051, function=function@entry=0x562312fad6e8 "dberr_t row_upd_sec_index_entry(upd_node_t, que_thr_t)") at assert.c:101
#4 0x00005623129111c1 in row_upd_sec_index_entry (node=node@entry=0x149fb8084370, thr=thr@entry=0x149fb808ddd8) at /test/10.7_dbg/storage/innobase/row/row0upd.cc:2051
#5 0x0000562312911fcf in row_upd_sec_step (thr=0x149fb808ddd8, node=0x149fb8084370) at /test/10.7_dbg/storage/innobase/row/row0upd.cc:2200
#6 row_upd (thr=0x149fb808ddd8, node=0x149fb8084370) at /test/10.7_dbg/storage/innobase/row/row0upd.cc:2936
#7 row_upd_step (thr=thr@entry=0x149fb808ddd8) at /test/10.7_dbg/storage/innobase/row/row0upd.cc:3051
#8 0x00005623128b6bb3 in row_update_for_mysql (prebuilt=0x149fb80837c8) at /test/10.7_dbg/storage/innobase/row/row0mysql.cc:1740
#9 0x0000562312740567 in ha_innobase::update_row (this=0x149fb80826e0, old_row=0x149fb8023dc8 "\240\001", new_row=0x149fb8023d98 "\370\002") at /test/10.7_dbg/storage/innobase/handler/ha_innodb.cc:8549
#10 0x00005623123a4fa1 in handler::ha_update_row (this=0x149fb80826e0, old_data=0x149fb8023dc8 "\240\001", new_data=0x149fb8023d98 "\370\002") at /test/10.7_dbg/sql/handler.cc:7567
#11 0x00005623120494c2 in write_record (thd=thd@entry=0x149fb8000db8, table=table@entry=0x149fb8024528, info=info@entry=0x149ffc919cc0, sink=sink@entry=0x0) at /test/10.7_dbg/sql/sql_insert.cc:2052
#12 0x0000562312054de4 in mysql_insert (thd=thd@entry=0x149fb8000db8, table_list=0x149fb8013d70, fields=@0x149fb8005fc8: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x149fb8014578, last = 0x149fb80146a8, elements = 2}, <No data fields>}, values_list=@0x149fb8006010: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x149fb8014c68, last = 0x149fb8014c68, elements = 1}, <No data fields>}, update_fields=@0x149fb8005ff8: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x562313663b80 <end_of_list>, last = 0x149fb8005ff8, elements = 0}, <No data fields>}, update_values=@0x149fb8005fe0: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x562313663b80 <end_of_list>, last = 0x149fb8005fe0, elements = 0}, <No data fields>}, duplic=DUP_REPLACE, ignore=false, result=0x0) at /test/10.7_dbg/sql/sql_insert.cc:1123
#13 0x000056231209aeaf in mysql_execute_command (thd=thd@entry=0x149fb8000db8, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/10.7_dbg/sql/sql_parse.cc:4565
#14 0x0000562312085ac3 in mysql_parse (thd=thd@entry=0x149fb8000db8, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x149ffc91a400) at /test/10.7_dbg/sql/sql_parse.cc:8030
#15 0x00005623120946c8 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x149fb8000db8, packet=packet@entry=0x149fb800b739 "REPLACE INTO t1 (b,i) VALUES ('foo',1)", packet_length=packet_length@entry=38, blocking=blocking@entry=true) at /test/10.7_dbg/sql/sql_class.h:1357
#16 0x0000562312097ae9 in do_command (thd=0x149fb8000db8, blocking=blocking@entry=true) at /test/10.7_dbg/sql/sql_parse.cc:1404
#17 0x000056231220ddd6 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x56231482b368, put_in_cache=put_in_cache@entry=true) at /test/10.7_dbg/sql/sql_connect.cc:1418
#18 0x000056231220e3db in handle_one_connection (arg=arg@entry=0x56231482b368) at /test/10.7_dbg/sql/sql_connect.cc:1312
#19 0x0000562312676ce4 in pfs_spawn_thread (arg=0x562314753bc8) at /test/10.7_dbg/storage/perfschema/pfs.cc:2201
#20 0x0000149fff9e8609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#21 0x0000149fff5d6293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

10.7.0 52505bf20de0ce77a5c0b0a74af021051987bb0d (Debug)

2021-08-21  6:50:30 4 [ERROR] InnoDB: Record in index `b` of table `test`.`t1` was not found on update: TUPLE (info_bits=0, 3 fields): {[8]    UW  (0x8EE2E0E255578A98),[4]    (0x80000001),[7]     B?(0x7FFFFFFF0F423F)} at: COMPACT RECORD(info_bits=0, 3 fields): {[8]4     : (0x34F3F6061BCE3AD8),[4]    (0x80000001),[7]     B?(0x7FFFFFFF0F423F)}

mysqld: /test/10.7_dbg/storage/innobase/row/row0upd.cc:2051: dberr_t row_upd_sec_index_entry(upd_node_t*, que_thr_t*): Assertion `0' failed.

Roel Van de Paar added a comment - 2021-08-20 20:51 - edited Various testcases in this bug still fail including the following testcase from Elena. CREATE TABLE t1 (pk INT AUTO_INCREMENT PRIMARY KEY, b TEXT, i INT, UNIQUE(i), UNIQUE(b)) ENGINE=InnoDB; INSERT INTO t1 (b,i) VALUES ('foo',1); SET STATEMENT time_zone= '-07:50' FOR ALTER TABLE t1 ADD SYSTEM VERSIONING; REPLACE INTO t1 (b,i) VALUES ('foo',1); 10.7.0 52505bf20de0ce77a5c0b0a74af021051987bb0d (Debug) mysqld: /test/10.7_dbg/storage/innobase/row/row0upd.cc:2051: dberr_t row_upd_sec_index_entry(upd_node_t*, que_thr_t*): Assertion `0' failed. 10.7.0 52505bf20de0ce77a5c0b0a74af021051987bb0d (Debug) Core was generated by `/test/MD160821-mariadb-10.7.0-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 0x149ffc91b700 (LWP 473547))] (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x0000149fff4d9859 in __GI_abort () at abort.c:79 #2 0x0000149fff4d9729 in __assert_fail_base (fmt=0x149fff66f588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x562312ed5b6b "0", file=0x562312fac310 "/test/10.7_dbg/storage/innobase/row/row0upd.cc", line=2051, function=<optimized out>) at assert.c:92 #3 0x0000149fff4eaf36 in __GI___assert_fail (assertion=assertion@entry=0x562312ed5b6b "0", file=file@entry=0x562312fac310 "/test/10.7_dbg/storage/innobase/row/row0upd.cc", line=line@entry=2051, function=function@entry=0x562312fad6e8 "dberr_t row_upd_sec_index_entry(upd_node_t*, que_thr_t*)") at assert.c:101 #4 0x00005623129111c1 in row_upd_sec_index_entry (node=node@entry=0x149fb8084370, thr=thr@entry=0x149fb808ddd8) at /test/10.7_dbg/storage/innobase/row/row0upd.cc:2051 #5 0x0000562312911fcf in row_upd_sec_step (thr=0x149fb808ddd8, node=0x149fb8084370) at /test/10.7_dbg/storage/innobase/row/row0upd.cc:2200 #6 row_upd (thr=0x149fb808ddd8, node=0x149fb8084370) at /test/10.7_dbg/storage/innobase/row/row0upd.cc:2936 #7 row_upd_step (thr=thr@entry=0x149fb808ddd8) at /test/10.7_dbg/storage/innobase/row/row0upd.cc:3051 #8 0x00005623128b6bb3 in row_update_for_mysql (prebuilt=0x149fb80837c8) at /test/10.7_dbg/storage/innobase/row/row0mysql.cc:1740 #9 0x0000562312740567 in ha_innobase::update_row (this=0x149fb80826e0, old_row=0x149fb8023dc8 "\240\001", new_row=0x149fb8023d98 "\370\002") at /test/10.7_dbg/storage/innobase/handler/ha_innodb.cc:8549 #10 0x00005623123a4fa1 in handler::ha_update_row (this=0x149fb80826e0, old_data=0x149fb8023dc8 "\240\001", new_data=0x149fb8023d98 "\370\002") at /test/10.7_dbg/sql/handler.cc:7567 #11 0x00005623120494c2 in write_record (thd=thd@entry=0x149fb8000db8, table=table@entry=0x149fb8024528, info=info@entry=0x149ffc919cc0, sink=sink@entry=0x0) at /test/10.7_dbg/sql/sql_insert.cc:2052 #12 0x0000562312054de4 in mysql_insert (thd=thd@entry=0x149fb8000db8, table_list=0x149fb8013d70, fields=@0x149fb8005fc8: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x149fb8014578, last = 0x149fb80146a8, elements = 2}, <No data fields>}, values_list=@0x149fb8006010: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x149fb8014c68, last = 0x149fb8014c68, elements = 1}, <No data fields>}, update_fields=@0x149fb8005ff8: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x562313663b80 <end_of_list>, last = 0x149fb8005ff8, elements = 0}, <No data fields>}, update_values=@0x149fb8005fe0: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x562313663b80 <end_of_list>, last = 0x149fb8005fe0, elements = 0}, <No data fields>}, duplic=DUP_REPLACE, ignore=false, result=0x0) at /test/10.7_dbg/sql/sql_insert.cc:1123 #13 0x000056231209aeaf in mysql_execute_command (thd=thd@entry=0x149fb8000db8, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/10.7_dbg/sql/sql_parse.cc:4565 #14 0x0000562312085ac3 in mysql_parse (thd=thd@entry=0x149fb8000db8, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x149ffc91a400) at /test/10.7_dbg/sql/sql_parse.cc:8030 #15 0x00005623120946c8 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x149fb8000db8, packet=packet@entry=0x149fb800b739 "REPLACE INTO t1 (b,i) VALUES ('foo',1)", packet_length=packet_length@entry=38, blocking=blocking@entry=true) at /test/10.7_dbg/sql/sql_class.h:1357 #16 0x0000562312097ae9 in do_command (thd=0x149fb8000db8, blocking=blocking@entry=true) at /test/10.7_dbg/sql/sql_parse.cc:1404 #17 0x000056231220ddd6 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x56231482b368, put_in_cache=put_in_cache@entry=true) at /test/10.7_dbg/sql/sql_connect.cc:1418 #18 0x000056231220e3db in handle_one_connection (arg=arg@entry=0x56231482b368) at /test/10.7_dbg/sql/sql_connect.cc:1312 #19 0x0000562312676ce4 in pfs_spawn_thread (arg=0x562314753bc8) at /test/10.7_dbg/storage/perfschema/pfs.cc:2201 #20 0x0000149fff9e8609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #21 0x0000149fff5d6293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 10.7.0 52505bf20de0ce77a5c0b0a74af021051987bb0d (Debug) 2021-08-21 6:50:30 4 [ERROR] InnoDB: Record in index `b` of table `test`.`t1` was not found on update: TUPLE (info_bits=0, 3 fields): {[8] UW (0x8EE2E0E255578A98),[4] (0x80000001),[7] B?(0x7FFFFFFF0F423F)} at: COMPACT RECORD(info_bits=0, 3 fields): {[8]4 : (0x34F3F6061BCE3AD8),[4] (0x80000001),[7] B?(0x7FFFFFFF0F423F)} mysqld: /test/10.7_dbg/storage/innobase/row/row0upd.cc:2051: dberr_t row_upd_sec_index_entry(upd_node_t*, que_thr_t*): Assertion `0' failed.

MariaDB Server

Server crash on DELETE with YEAR field with truncated expr