[MDEV-16429] Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' fails upon attempt to update virtual column on partitioned versioned table Created: 2018-06-07  Updated: 2021-03-05  Resolved: 2018-09-21

Status: Closed
Project: MariaDB Server
Component/s: Partitioning, Versioned Tables, Virtual Columns
Affects Version/s: 10.3
Fix Version/s: 10.3.10, 10.2.20

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Nikita Malyavin
Resolution: Fixed Votes: 0
Labels: affects-tests

Issue Links:
Duplicate
duplicates MDEV-17755 Assertion `!table || (!table->read_se... Closed

 Description   

Note: I couldn't get rid of versioning in the scenario, even though it's unclear how it is related. Partitioning is also needed, it doesn't have to be BY HASH, BY SYSTEM_TIME will also do, I didn't try other ones.

--source include/have_partition.inc
 
CREATE OR REPLACE TABLE t1 (
  pk INT PRIMARY KEY,
  c CHAR(3) NOT NULL,
  v CHAR(4) AS (c) VIRTUAL
) WITH SYSTEM VERSIONING PARTITION BY HASH(pk);
 
INSERT INTO t1 (pk,c) VALUES (1,'foo'),(2,'bar');
UPDATE t1 SET v = 'qux' WHERE pk = 2;
 
# Cleanup
DROP TABLE t1;

10.3 62d21dda

mysqld: /data/src/10.3/sql/field.cc:7162: virtual String* Field_string::val_str(String*, String*): Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed.
180608  2:00:54 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f511cde1ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x00005563bd5d3b3f in Field_string::val_str (this=0x7f50fc00ee58, val_buffer=0x7f5112f41660, val_ptr=0x7f5112f41660) at /data/src/10.3/sql/field.cc:7162
#9  0x00005563bd20364d in Field::val_str (this=0x7f50fc00ee58, str=0x7f5112f41660) at /data/src/10.3/sql/field.h:834
#10 0x00005563bd5e3202 in Field::save_in_field_str (this=0x7f50fc00ee58, to=0x7f50fc00ef48) at /data/src/10.3/sql/field.h:628
#11 0x00005563bd5e468f in Field_str::save_in_field (this=0x7f50fc00ee58, to=0x7f50fc00ef48) at /data/src/10.3/sql/field.h:1716
#12 0x00005563bd5e3470 in Field::store_field (this=0x7f50fc00ef48, from=0x7f50fc00ee58) at /data/src/10.3/sql/field.h:789
#13 0x00005563bd5ec607 in field_conv_incompatible (to=0x7f50fc00ef48, from=0x7f50fc00ee58) at /data/src/10.3/sql/field_conv.cc:836
#14 0x00005563bd5ec663 in field_conv (to=0x7f50fc00ef48, from=0x7f50fc00ee58) at /data/src/10.3/sql/field_conv.cc:849
#15 0x00005563bd6204ad in save_field_in_field (from=0x7f50fc00ee58, null_value=0x7f50fc112f76, to=0x7f50fc00ef48, no_conversions=false) at /data/src/10.3/sql/item.cc:6797
#16 0x00005563bd6206ee in Item_field::save_in_field (this=0x7f50fc112f00, to=0x7f50fc00ef48, no_conversions=false) at /data/src/10.3/sql/item.cc:6848
#17 0x00005563bd427773 in TABLE::update_virtual_fields (this=0x7f50fc1107d0, h=0x7f50fc111cc8, update_mode=VCOL_UPDATE_FOR_READ) at /data/src/10.3/sql/table.cc:7661
#18 0x00005563bd5fc189 in handler::ha_index_read_map (this=0x7f50fc111cc8, buf=0x7f50fc00ece8 "\375\002", key=0x7f50fc181790 "\002", keypart_map=1, find_flag=HA_READ_KEY_EXACT) at /data/src/10.3/sql/handler.cc:2829
#19 0x00005563bd603563 in handler::read_range_first (this=0x7f50fc111cc8, start_key=0x7f50fc111db0, end_key=0x7f50fc111dd0, eq_range_arg=true, sorted=true) at /data/src/10.3/sql/handler.cc:5565
#20 0x00005563bd4b680c in handler::multi_range_read_next (this=0x7f50fc111cc8, range_info=0x7f50fc113900) at /data/src/10.3/sql/multi_range_read.cc:291
#21 0x00005563bd4b69ee in Mrr_simple_index_reader::get_next (this=0x7f50fc112278, range_info=0x7f50fc113900) at /data/src/10.3/sql/multi_range_read.cc:323
#22 0x00005563bd4b963e in DsMrr_impl::dsmrr_next (this=0x7f50fc112138, range_info=0x7f50fc113900) at /data/src/10.3/sql/multi_range_read.cc:1393
#23 0x00005563bdce55ee in ha_myisam::multi_range_read_next (this=0x7f50fc111cc8, range_info=0x7f50fc113900) at /data/src/10.3/storage/myisam/ha_myisam.cc:2491
#24 0x00005563bdd683aa in ha_partition::handle_ordered_index_scan (this=0x7f50fc111418, buf=0x7f50fc00ece8 "\375\002", reverse_order=false) at /data/src/10.3/sql/ha_partition.cc:7528
#25 0x00005563bdd6513e in ha_partition::multi_range_read_next (this=0x7f50fc111418, range_info=0x7f5112f41ee0) at /data/src/10.3/sql/ha_partition.cc:6473
#26 0x00005563bd76aedc in QUICK_RANGE_SELECT::get_next (this=0x7f50fc11b170) at /data/src/10.3/sql/opt_range.cc:11442
#27 0x00005563bd77c866 in rr_quick (info=0x7f5112f42170) at /data/src/10.3/sql/records.cc:365
#28 0x00005563bd2715f9 in READ_RECORD::read_record (this=0x7f5112f42170) at /data/src/10.3/sql/records.h:73
#29 0x00005563bd402759 in mysql_update (thd=0x7f50fc000b00, table_list=0x7f50fc014dd0, fields=..., values=..., conds=0x7f50fc0157b8, order_num=0, order=0x0, limit=18446744073709551615, handle_duplicates=DUP_ERROR, ignore=false, found_return=0x7f5112f426f0, updated_return=0x7f5112f427b0) at /data/src/10.3/sql/sql_update.cc:736
#30 0x00005563bd30c533 in mysql_execute_command (thd=0x7f50fc000b00) at /data/src/10.3/sql/sql_parse.cc:4575
#31 0x00005563bd31784b in mysql_parse (thd=0x7f50fc000b00, rawbuf=0x7f50fc014cd8 "UPDATE t1 SET v = 'qux' WHERE pk = 2", length=36, parser_state=0x7f5112f435f0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:8076
#32 0x00005563bd304b1e in dispatch_command (command=COM_QUERY, thd=0x7f50fc000b00, packet=0x7f50fc145741 "UPDATE t1 SET v = 'qux' WHERE pk = 2", packet_length=36, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1847
#33 0x00005563bd303542 in do_command (thd=0x7f50fc000b00) at /data/src/10.3/sql/sql_parse.cc:1392
#34 0x00005563bd468cc7 in do_handle_one_connection (connect=0x5563c0232d90) at /data/src/10.3/sql/sql_connect.cc:1402
#35 0x00005563bd468a4b in handle_one_connection (arg=0x5563c0232d90) at /data/src/10.3/sql/sql_connect.cc:1308
#36 0x00005563bd8f89a9 in pfs_spawn_thread (arg=0x5563c0246630) at /data/src/10.3/storage/perfschema/pfs.cc:1862
#37 0x00007f511eab8494 in start_thread (arg=0x7f5112f44700) at pthread_create.c:333
#38 0x00007f511ce9e93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Reproducible with at least InnoDB and MyISAM.
No obvious problems on a non-debug build (UPDATE fails with ER_WARNING_NON_DEFAULT_VALUE_FOR_GENERATED_COLUMN as expected).



 Comments   
Comment by Nikita Malyavin [ 2018-08-20 ]

Literally the same bug can be achieved without system versioning:

unknown [test]> CREATE OR REPLACE TABLE t1 (   pk INT PRIMARY KEY,   c CHAR(3) NOT NULL,   v CHAR(4) AS (c) VIRTUAL ) PARTITION BY HASH(pk);
INSERT INTO t1 (pk,c) VALUES (1,'foo'),(2,'bar');
UPDATE t1 SET pk=2, v= 'wqeq' WHERE pk*2 = 4;

That's because:
1. We ALWAYS modify key when versioned
2. No (row_end, pk) index, thus versioned search is always linear

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