[MDEV-31724] Compressed varchar values lost on joins when sorting on columns from joined table(s) Created: 2023-07-17 Updated: 2023-08-15 Resolved: 2023-08-15 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Character Sets, Data types, Server |
| Affects Version/s: | 10.4.30, 10.6.14, 10.11.4 |
| Fix Version/s: | 10.8.8, 10.4.32, 10.5.23, 10.6.16, 10.10.7, 10.11.6, 11.0.4, 11.1.2, 11.2.1 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Vladimir "Bob" Zakharychev | Assignee: | Alexander Barkov |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
When (inner or outer) joining a table with compressed varchar column(s) to another table and sorting on column(s) of the joined table, compressed values are replaced with NULLs in returned result set. We heuristically assume that minimum varchar length to compress is 100, values shorter than that are not compressed and returned correctly. A minimal reproducible test case (reproduced in 10.11.4 and 10.6.14, probably affects previous releases as well):
DDL and queries to reproduce:
|
| Comments |
| Comment by Daniel Black [ 2023-07-17 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
Thanks for the test case. Much appreciated. Looks highly related (and probably duplicate) of | ||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alexander Barkov [ 2023-07-21 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
Repeatable with this script with one table with InnoDB and MyISAM:
| ||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alexander Barkov [ 2023-07-21 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
The problem happens because do_varstring* calculate prefixes of the data, but does not take into account that the data is compressed. The problem is also repeatable in the following scripts (with InnoDB and MyISAM): do_varstring1:
do_varstring2
do_varstring1_mb:
do_varstring2_mb
| ||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alexander Barkov [ 2023-07-21 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
sanja, please review a fix: | ||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Black [ 2023-07-27 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
FYI tested
Previously warnings were generated. Up to you to make it as a duplicate or add more test cases. | ||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Oleksandr Byelkin [ 2023-08-14 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
The commit is OK, not OK is using varstring1 varstring2 as something selfdescriptive or well known. Please add appropriate description to them | ||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alexander Barkov [ 2023-08-15 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
sanja thanks for the review. I've updated the comments in the commit and inside the code not to use varstring1 and varstring2. Pushed. |