[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 Created: 2018-11-26  Updated: 2020-08-06  Resolved: 2019-06-15

Status: Closed
Project: MariaDB Server
Component/s: Virtual Columns
Affects Version/s: 10.2, 10.3, 10.4
Fix Version/s: 10.2.25, 10.3.16, 10.4.6

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by MDEV-19771 REPLACE on table with virtual_field c... Closed
Relates
relates to MDEV-20618 Assertion `btr_validate_index(index, ... Closed

 Description   

SET sql_mode= STRICT_ALL_TABLES;
 
CREATE TABLE t1 ( 
  pk INT,
  i TINYINT,
  vi TINYINT AS (i+1) PERSISTENT,
  PRIMARY KEY(pk)
);
INSERT INTO t1 (pk,i) VALUES (1,1);
TRUNCATE TABLE t1;
INSERT IGNORE INTO t1 (pk,i) VALUES (1,127);
REPLACE INTO t1 (pk,i) VALUES (1,2);
 
# Cleanup
DROP TABLE t1;

10.2 3728b11f87

mysqld: /data/src/10.2/sql/sql_error.cc:380: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.
181126 13:30:08 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f83a52d6ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x0000555a23688d2d in Diagnostics_area::set_ok_status (this=0x7f8384005c98, affected_rows=2, last_insert_id=0, message=0x0) at /data/src/10.2/sql/sql_error.cc:380
#9  0x0000555a2363b597 in my_ok (thd=0x7f8384000b00, affected_rows=2, id=0, message=0x0) at /data/src/10.2/sql/sql_class.h:4506
#10 0x0000555a236912ee in mysql_insert (thd=0x7f8384000b00, table_list=0x7f8384012540, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_REPLACE, ignore=false) at /data/src/10.2/sql/sql_insert.cc:1217
#11 0x0000555a236b866b in mysql_execute_command (thd=0x7f8384000b00) at /data/src/10.2/sql/sql_parse.cc:4436
#12 0x0000555a236c3b5d in mysql_parse (thd=0x7f8384000b00, rawbuf=0x7f8384012448 "REPLACE INTO t1 (pk,i) VALUES (1,2)", length=35, parser_state=0x7f839b582200, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:8013
#13 0x0000555a236b1495 in dispatch_command (command=COM_QUERY, thd=0x7f8384000b00, packet=0x7f838408c171 "REPLACE INTO t1 (pk,i) VALUES (1,2)", packet_length=35, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1824
#14 0x0000555a236afdf8 in do_command (thd=0x7f8384000b00) at /data/src/10.2/sql/sql_parse.cc:1378
#15 0x0000555a23802537 in do_handle_one_connection (connect=0x555a270d0930) at /data/src/10.2/sql/sql_connect.cc:1335
#16 0x0000555a238022c4 in handle_one_connection (arg=0x555a270d0930) at /data/src/10.2/sql/sql_connect.cc:1241
#17 0x0000555a23c27f46 in pfs_spawn_thread (arg=0x555a270340b0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
#18 0x00007f83a6d92494 in start_thread (arg=0x7f839b583700) at pthread_create.c:333
#19 0x00007f83a539393f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Non-debug build doesn't crash, but I find the behavior somewhat odd:

MariaDB [test]> INSERT INTO t1 (pk,i) VALUES (1,1);
Query OK, 1 row affected (0.04 sec)
 
MariaDB [test]> TRUNCATE TABLE t1;
Query OK, 0 rows affected (0.37 sec)
 
MariaDB [test]> INSERT IGNORE INTO t1 (pk,i) VALUES (1,127);
Query OK, 1 row affected, 1 warning (0.04 sec)
 
MariaDB [test]> SHOW WARNINGS;
+---------+------+---------------------------------------------+
| Level   | Code | Message                                     |
+---------+------+---------------------------------------------+
| Warning | 1264 | Out of range value for column 'vi' at row 1 |
+---------+------+---------------------------------------------+
1 row in set (0.00 sec)
 
MariaDB [test]> REPLACE INTO t1 (pk,i) VALUES (1,2);
ERROR 1264 (22003): Out of range value for column 'vi' at row 1

So, INSERT which creates the out-of-range value succeeds, although with a warning, but REPLACE which is supposed to replace the value with a valid one fails.

Neither is reproducible on 10.1 – no assertion failure, and REPLACE succeeds.

There is some resemblance of the test case with MDEV-17834, might be related.



 Comments   
Comment by Michael Widenius [ 2019-06-15 ]

Problem was that we did not ignore warnings from virtual fields when updated virtual fields for to-be-replaced-row.

Generated at Thu Feb 08 08:39:29 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.