Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Duplicate
-
10.5, 10.6, 10.10(EOL), 10.11, 11.0(EOL), 11.1(EOL)
-
None
Description
In MySQL, user variable names are limited to 64 symbols. There is no such limitation in MariaDB. The KB page about identifiers lists various length limits depending on the object, but says nothing about user variables.
Long names can be unexpected by other components. For example, they cause a problem with performance schema in 10.5+.
--source include/have_perfschema.inc
|
|
set @v123456789_123456789_123456789_123456789_123456789_123456789_1234 = 1; |
SELECT * FROM performance_schema.user_variables_by_thread; |
10.5 7c9837ce |
mariadbd: /data/src/10.5/storage/perfschema/table_helper.cc:840: void PFS_variable_name_row::make_row(const char*, size_t): Assertion `length <= NAME_CHAR_LEN' failed.
|
230820 17:31:29 [ERROR] mysqld got signal 6 ;
|
|
#9 0x00007f4541453df2 in __GI___assert_fail (assertion=0x55e9f57f53c0 "length <= NAME_CHAR_LEN", file=0x55e9f57f3aa0 "/data/src/10.5/storage/perfschema/table_helper.cc", line=840, function=0x55e9f57f5320 "void PFS_variable_name_row::make_row(const char*, size_t)") at ./assert/assert.c:101
|
#10 0x000055e9f40816e8 in PFS_variable_name_row::make_row (this=0x61b00003aa98, str=0x60f000012520 "v123456789_123456789_123456789_123456789_123456789_123456789_1234", length=65) at /data/src/10.5/storage/perfschema/table_helper.cc:840
|
#11 0x000055e9f40aaefc in User_variables::materialize (this=0x60d000010a18, pfs=0x7f453f3ede80, thd=0x62b000069218) at /data/src/10.5/storage/perfschema/table_uvar_by_thread.cc:109
|
#12 0x000055e9f40ab7c6 in table_uvar_by_thread::materialize (this=0x60d0000109f0, thread=0x7f453f3ede80) at /data/src/10.5/storage/perfschema/table_uvar_by_thread.cc:258
|
#13 0x000055e9f40ab3e6 in table_uvar_by_thread::rnd_next (this=0x60d0000109f0) at /data/src/10.5/storage/perfschema/table_uvar_by_thread.cc:201
|
#14 0x000055e9f3faa831 in ha_perfschema::rnd_next (this=0x61a00002beb8, buf=0x61900009a1e0 "\377") at /data/src/10.5/storage/perfschema/ha_perfschema.cc:358
|
#15 0x000055e9f3745bd5 in handler::ha_rnd_next (this=0x61a00002beb8, buf=0x61900009a1e0 "\377") at /data/src/10.5/sql/handler.cc:3120
|
#16 0x000055e9f3b98298 in rr_sequential (info=0x62b00003cd68) at /data/src/10.5/sql/records.cc:519
|
#17 0x000055e9f2d67764 in READ_RECORD::read_record (this=0x62b00003cd68) at /data/src/10.5/sql/records.h:80
|
#18 0x000055e9f30795a4 in join_init_read_record (tab=0x62b00003cca0) at /data/src/10.5/sql/sql_select.cc:22141
|
#19 0x000055e9f307274c in sub_select (join=0x62b00003b410, join_tab=0x62b00003cca0, end_of_records=false) at /data/src/10.5/sql/sql_select.cc:21174
|
#20 0x000055e9f30706d4 in do_select (join=0x62b00003b410, procedure=0x0) at /data/src/10.5/sql/sql_select.cc:20696
|
#21 0x000055e9f2ffc22d in JOIN::exec_inner (this=0x62b00003b410) at /data/src/10.5/sql/sql_select.cc:4602
|
#22 0x000055e9f2ff9812 in JOIN::exec (this=0x62b00003b410) at /data/src/10.5/sql/sql_select.cc:4382
|
#23 0x000055e9f2ffdb2d in mysql_select (thd=0x62b000069218, tables=0x62b0000389e0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x62b00003b3e0, unit=0x62b00006d3c8, select_lex=0x62b000038318) at /data/src/10.5/sql/sql_select.cc:4859
|
#24 0x000055e9f2fce892 in handle_select (thd=0x62b000069218, lex=0x62b00006d300, result=0x62b00003b3e0, setup_tables_done_option=0) at /data/src/10.5/sql/sql_select.cc:450
|
#25 0x000055e9f2f37887 in execute_sqlcom_select (thd=0x62b000069218, all_tables=0x62b0000389e0) at /data/src/10.5/sql/sql_parse.cc:6341
|
#26 0x000055e9f2f2637b in mysql_execute_command (thd=0x62b000069218) at /data/src/10.5/sql/sql_parse.cc:4018
|
#27 0x000055e9f2f4284d in mysql_parse (thd=0x62b000069218, rawbuf=0x62b000038238 "SELECT * FROM performance_schema.user_variables_by_thread", length=57, parser_state=0x7f4539c90c10, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:8118
|
#28 0x000055e9f2f181ee in dispatch_command (command=COM_QUERY, thd=0x62b000069218, packet=0x629000253219 "", packet_length=57, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1891
|
#29 0x000055e9f2f14b81 in do_command (thd=0x62b000069218) at /data/src/10.5/sql/sql_parse.cc:1375
|
#30 0x000055e9f3363be7 in do_handle_one_connection (connect=0x608000002b38, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1416
|
#31 0x000055e9f33635af in handle_one_connection (arg=0x608000002ab8) at /data/src/10.5/sql/sql_connect.cc:1318
|
#32 0x000055e9f3fb0e18 in pfs_spawn_thread (arg=0x615000005318) at /data/src/10.5/storage/perfschema/pfs.cc:2201
|
#33 0x00007f45414a7fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
|
#34 0x00007f45415285bc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
|
The use case is not artificial. For example, Spider creates user variables which include the full database name + table name + some other parts, so they can easily exceed 64 symbols (see MDEV-31968):
set session time_zone = '+00:00';set @`spider_lc_./spider_remote_db/sufficiently_but_not_exceessively_long_table_name` = '-2cf05d72f7ce-35bcab-./test/t_spider-' |
Attachments
Issue Links
- is duplicated by
-
MDEV-23665 Assertion `length <= 64' failed in PFS_variable_name_row::make_row and Assertion `length <= NAME_CHAR_LEN' failed on performance_schema related SELECT
- Open
- relates to
-
MDEV-31968 Spider uses too long variable names on a remote server
- Open