MySQL Bugs: #115635: The collation_comnection was not marked as changed

Bug #115635	The collation_comnection was not marked as changed
Submitted:	18 Jul 2024 3:01	Modified:	18 Jul 2024 11:59
Reporter:	Carl Wang	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	8.0	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
The collation_connection was not marked as changed, which resulted in the proxy not being able to retrieve the collation_connection in the return packet even when the set session_track_state_change=on was set, leading to synchronization errors in the read-only node state of the proxy.

In sql/session_tracker.cc https://github.com/mysql/mysql-server/blob/trunk/sql/session_tracker.cc
:704
!m_changed variable will not be written to buff.

And in sql/set_var.cc int set_var_collation_client::update(THD *thd)
collation_connection was not marked as changed.

How to repeat:
set session_track_state_change=on, session_track_schema=on, session_track_system_variables='*', session_track_transaction_info='CHARACTERISTICS';

SET NAMES utf8mb4 COLLATE utf8mb4_general_ci;

The effect is:
set character_set_client=utf8mb4
set character_set_connection=utf8mb4
set character_set_results=utf8mb4
set collation_connection =utf8mb4_general_ci

But the responding packet from db only contains character_set_client, character_set_connection, character_set_results, without collation_connection

I mean what should i do to track collation_collection in my proxy.

https://dev.mysql.com/doc/refman/8.4/en/charset-connection.html
i found that collation_connection will be implicitly set when character_set_connection is set, but why thd variables not contains character_set_connection, but contains collation_connection?

sql/set_var.cc :2098

set names utf8mb4;

set character_set_connection utf8mb4;

The two ways will lead to different collation_collection.
One is utf8mb4_general_ci
The other is utf8mb4_9000_ai_ci;

Hi Mr. Wang,

Thank you for your bug report.

However, we are not able to repeat your bug report.

We have set the character sets and collations, but we do not see what is the bug that you are reporting.

Which SQL commands should we also run in order for a bug to show up ????

Cna't repeat.

Thanks

You should open session_track

and use sql:
SET NAMES utf8mb4 COLLATE utf8mb4_general_ci

and use tcpdump to find out that
collation_connection is not in the response packet

i was making a database proxy

i need to get collation_connection state to sync it to another mysql instance.

i know that setting character_set_connection will implicitly change the collation_connection using default related collation_connection.

but if i use 'SET NAMES utf8mb4 COLLATE utf8mb4_general_ci' on a mysql instance A in a cluster.

i can not get collation_connection in the response packet. Then i can't sync the state to mysql instance B in the above cluster.

Because by default, the related DEFAULT_COLLATE_NAME is utf8mb4_0900_ai_ci in mysql>=8.0

So i set character_set_connection in the mysql instance B, the collation_name will set to utf8mb4_0900_ai_ci, but not utf8mb4_general_ci.

Hi Mr. Wang,

We are afraid that we con not help you with a design of your proxy.

This is a forum for the reports for the bugs in our server , clients and other our programs.

We can however give you some small hints .......

Client is the one that sets client character set and collation. Server is the one that sets connection character set and collation.

We do not know what kind of design are you making, but if your proxy is between the client and the server, then your proxy should definitely present to server the client's collation as well.

All of this works just fine in our system and on some already existing proxies.

OK

why collation_connection's state in not in the response packet.

when i use set names xxx;

collation_connection will change, won't it?

Mr. Wang,

This is not a forum for helping developers making their own products.

You have to get that collation from the server......

Also, do note that we already have our proxy, named MySQL Router, so please ......

Not a bug !!!!!!!!