[MDEV-27320] Redundant addon key in Sort_param Created: 2021-12-20  Updated: 2021-12-20

Status: Open
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.5, 10.6, 10.7, 10.8
Fix Version/s: 10.5

Type: Bug Priority: Major
Reporter: Alexander Barkov Assignee: Alexander Barkov
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The problem is repeatable in versions 10.5 to 10.8. But it's probably repeatable in earlier version as well. It needs to be checked.

I start mariadbd in gdb and set a break point in "make_sortkey".

The run this script:

SET NAMES latin1;
 
CREATE OR REPLACE TABLE t1 (
 
  code INT NOT NULL,
 
  str VARCHAR(1) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL
 
) ENGINE=MyISAM;
 
DELIMITER $$
 
FOR i IN 0x0000..0x2FFF
 
DO
 
  INSERT INTO t1 VALUES (i, CHAR(i USING utf32));
 
END FOR;
 
$$
 
DELIMITER ;
 
SELECT HEX(code) FROM t1 ORDER BY HEX(str);
 
DROP TABLE t1;

When the break-point hits, I print variables as follows:

(gdb) p param->local_sortorder
 
$19 = {m_array = 0x7fff9001acf8, m_size = 1}
 
 
 
(gdb) p dbug_print_item(param->local_sortorder.m_array[0].item)
 
$20 = 0x21b45a0 <dbug_item_print_buf> "hex(t1.str)"
 
 
 
(gdb) p param->addon_fields[0]
 
$25 = {static size_of_length_field = 2, m_field_descriptors = {m_array = 0x7fff90066cf8, m_size = 2}, m_addon_buf = 0x0, 
  m_addon_buf_length = 0, m_using_packed_addons = false}
 
 
 
(gdb) p param->addon_fields[0].m_field_descriptors.m_array[0].field->field_name
 
$29 = {str = 0x7fff9007bff9 "code", length = 4}
 
 
 
(gdb) p param->addon_fields[0].m_field_descriptors.m_array[1].field->field_name
 
$30 = {str = 0x7fff9007bffe "str", length = 3}

Notice, param contains one sort key HEX(str), and two addon fields:

  • code
  • str

The field code is used in SELECT list in HEX(code), so it's clear why it in addon fields.

The field str is not used anywhere except ORDER BY HEX(str). It's not clear why it is in addon fields. It should be enough to have this field in sort keys only.
Generated at Thu Feb 08 09:52:01 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.