[MDEV-23626] CONNECT VIR tables return inconsistent error for UPDATE Created: 2020-08-29  Updated: 2022-04-04  Resolved: 2022-04-04

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - Connect
Affects Version/s: 10.5.5
Fix Version/s: 10.4.25, 10.5.16, 10.6.8, 10.7.4, 10.8.3, 10.9.1

Type: Bug Priority: Trivial
Reporter: Federico Razzoli Assignee: Anel Husakovic
Resolution: Fixed Votes: 0
Labels: errors


 Description   

CONNECT tables of type VIRT are read-only. They return the same error for TRUNCATE, DELETE, INSERT statements, but a different error for UPDATE (same number, different message).

MariaDB [test]> CREATE OR REPLACE TABLE numbers
    ->     ENGINE = CONNECT,
    ->     TABLE_TYPE = VIR,
    ->     BLOCK_SIZE = 3
    -> ;
Query OK, 0 rows affected (0.005 sec)
 
MariaDB [test]> TRUNCATE TABLE numbers;
ERROR 1296 (HY000): Got error 174 'Virtual tables are read only' from CONNECT
MariaDB [test]> DELETE FROM numbers WHERE n = 1;
ERROR 1296 (HY000): Got error 174 'Virtual tables are read only' from CONNECT
MariaDB [test]> INSERT INTO numbers (n) VALUES (1);
ERROR 1296 (HY000): Got error 174 'Virtual tables are read only' from CONNECT
MariaDB [test]> UPDATE numbers SET n = 10 WHERE n = 1;
ERROR 1296 (HY000): Got error 174 'Table numbers invalid for update' from CONNECT



 Comments   
Comment by Anel Husakovic [ 2020-09-07 ]

Hi bertrandop can you please take a look a patch.
Here is the backtrace that matters

#0  CntOpenTable (g=0x7fffd002bf40, tdbp=0x7fffcbfff1f0, mode=MODE_UPDATE, c1=0x7fffcbfff2b0 "n", c2=0x7fffcbfff2b8 "n", del=false) at /home/anel/mariadb/10.4/storage/connect/connect.cc:242
#1  0x00007fffef96b97e in ha_connect::OpenTable (this=0x7fffd002a328, g=0x7fffd002bf40, del=false) at /home/anel/mariadb/10.4/storage/connect/ha_connect.cc:2027
#2  0x00007fffef97264a in ha_connect::rnd_init (this=0x7fffd002a328, scan=false) at /home/anel/mariadb/10.4/storage/connect/ha_connect.cc:4082
#3  0x00007fffef9719c1 in ha_connect::index_init (this=0x7fffd002a328, idx=0, sorted=true) at /home/anel/mariadb/10.4/storage/connect/ha_connect.cc:3770
#4  0x0000555555cc0c6d in handler::ha_index_init (this=0x7fffd002a328, idx=0, sorted=true) at /home/anel/mariadb/10.4/sql/handler.h:3206
#5  0x0000555556267bad in QUICK_RANGE_SELECT::reset (this=0x7fffd0076ba0) at /home/anel/mariadb/10.4/sql/opt_range.cc:12159
#6  0x0000555555e84564 in mysql_update (thd=0x7fffd0000d50, table_list=0x7fffd0015730, fields=..., values=..., conds=0x7fffd0016188, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7fffec5fdda0, updated_return=0x7fffec5fde60) at /home/anel/ma
riadb/10.4/sql/sql_update.cc:920
#7  0x0000555555d741a8 in mysql_execute_command (thd=0x7fffd0000d50) at /home/anel/mariadb/10.4/sql/sql_parse.cc:4360
#8  0x0000555555d8027b in mysql_parse (thd=0x7fffd0000d50, rawbuf=0x7fffd0015638 "UPDATE numbers SET n = 10 WHERE n = 1", length=37, parser_state=0x7fffec5fe4d0, is_com_multi=false, is_next_command=false) at /home/anel/mariadb/10.4/sql/sql_parse.cc:7896
#9  0x0000555555d6c7b9 in dispatch_command (command=COM_QUERY, thd=0x7fffd0000d50, packet=0x7fffd0008751 "UPDATE numbers SET n = 10 WHERE n = 1", packet_length=37, is_com_multi=false, is_next_command=false) at /home/anel/mariadb/10.4/sql/sql_parse.cc:1834
#10 0x0000555555d6af5a in do_command (thd=0x7fffd0000d50) at /home/anel/mariadb/10.4/sql/sql_parse.cc:1352
#11 0x0000555555ef4c3a in do_handle_one_connection (connect=0x5555582c2b60) at /home/anel/mariadb/10.4/sql/sql_connect.cc:1412
#12 0x0000555555ef4989 in handle_one_connection (arg=0x5555582c2b60) at /home/anel/mariadb/10.4/sql/sql_connect.cc:1316
#13 0x00005555568f988c in pfs_spawn_thread (arg=0x555558234390) at /home/anel/mariadb/10.4/storage/perfschema/pfs.cc:1869
#14 0x00007ffff688f6db in start_thread (arg=0x7fffec5ff700) at pthread_create.c:463
#15 0x00007ffff504ea3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Comment by Olivier Bertrand [ 2020-09-08 ]

Thanks for the patch. BTW I didn't think anyone could be interested by the VIR table type

Generated at Thu Feb 08 09:23:49 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.