[MDEV-27177] OLD_MODE Ignored during initial hand shake for utf8 Created: 2021-12-06  Updated: 2023-03-03

Status: Confirmed
Project: MariaDB Server
Component/s: Character Sets
Affects Version/s: 10.6.5, 10.6, 10.7
Fix Version/s: 10.6

Type: Bug Priority: Major
Reporter: Roy Bellingan Assignee: Rucha Deodhar
Resolution: Unresolved Votes: 2
Labels: None
Environment:

Suse Tumbleweed, just compiled from source the 10.6.5 @git 109fc67d4da46d52d2a96528eaea3b0ef6275692


Issue Links:
Blocks
blocks MDEV-26105 MariaDB 10.6 cannot be used from C# c... Closed

 Description   

In the config file I have

old_mode=''

https://mariadb.com/kb/en/old-mode/

Which is correctly parsed and used

SELECT @@OLD_MODE, @@GLOBAL.OLD_MODE;
+------------+-------------------+
| @@OLD_MODE | @@GLOBAL.OLD_MODE |
+------------+-------------------+
|            |                   |
+------------+-------------------+

Correctly a query like that is interpreted correctly as

SELECT @@character_set_client, @@character_set_connection, @@collation_connection;
+------------------------+----------------------------+------------------------+
| @@character_set_client | @@character_set_connection | @@collation_connection |
+------------------------+----------------------------+------------------------+
| latin1                 | latin1                     | latin1_bin             |
+------------------------+----------------------------+------------------------+
 
SET character_set_client = 'utf8';
SET character_set_connection = 'utf8';
SET collation_connection = 'utf8_general_ci';
 
SELECT @@character_set_client, @@character_set_connection, @@collation_connection;
+------------------------+----------------------------+------------------------+
| @@character_set_client | @@character_set_connection | @@collation_connection |
+------------------------+----------------------------+------------------------+
| utf8mb4                | utf8mb4                    | utf8mb4_general_ci     |
+------------------------+----------------------------+------------------------+

The problem arise when a client is connecting and issue during the handshake a command to
Charset: utf8 COLLATE utf8_general_ci (33)

(For example a default-character-set=utf8 in the my.cnf file)

now

SELECT @@character_set_client, @@character_set_connection, @@collation_connection;
+------------------------+----------------------------+------------------------+
| @@character_set_client | @@character_set_connection | @@collation_connection |
+------------------------+----------------------------+------------------------+
| utf8mb3                | utf8mb3                    | utf8mb3_general_ci     |
+------------------------+----------------------------+------------------------+
 
status;
--------------
mysql  Ver 15.1 Distrib 10.6.5-MariaDB, for Linux (x86_64) using  EditLine wrapper
 
Connection id:          28
/* omissis */
Server version:         10.6.5-MariaDB-debug Source distribution
Protocol version:       10
 
Server characterset:    utf8mb4
Db     characterset:    utf8mb4
Client characterset:    utf8mb3
Conn.  characterset:    utf8mb3

I will now check in the source code more info about that



 Comments   
Comment by Roy Bellingan [ 2021-12-06 ]

To avoid smapping many email with all the update I discover while working on this bug I will just link and write on a gist https://gist.github.com/RoyBellingan/7e7e90af615bf16057695533a9f781a9

But yes looks like on connection is ignored.

In short the problem is the following:

the collation 33 is already been remapped internally NOT as utf8_general_ci and later upgraded to either mb3 or mb4, but is now defaulted to an mb3 one...

Written like that utf8mb3

But the internal function get_collation_name_alias https://github.com/MariaDB/server/blob/109fc67d4da46d52d2a96528eaea3b0ef6275692/mysys/charset.c#L749
expect it to be written like utf8_mb3

.

I think we need a function that internally has the list of the old ID, and based on the old_mode flag decide to upcast to mb3 (which in this case is do nothing) or mb4.

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