Details
-
Task
-
Status: Open (View Workflow)
-
Critical
-
Resolution: Unresolved
-
None
-
Q4/2025 Server Development
Description
it is 10 year old story. Of course, the idea was not to keep 2 libmariadbs, but get rid of the one inside the server. The reason is incompatibility of MYSQL structure, and direct use of its members inside the server's slave code. mysql->net can't be used, mysql->net.vio can't be used. read_pos or whatever, it is all not using MYSQL* as opaque thing, and it is not using only official APIs to access it.
⸺ wlad, https://mariadb.zulipchat.com/#narrow/channel/118759-general/topic/.60sql-common.60.20vs.2E.20.60libmariadb.60/near/532951021
November 2025 update
I will reduce the scope of this task to only client-like components.
It will not solve the 2-libmariadb issue in full, but will allow Replication’s MDEV-19248 to move forward without compromising on a tangent.
The server-side components make extensive use of mysql->net and mysql->net.vio.
For them, either
- They must refactor to avoid overlapping with client connection code, or
- The C Connector must first officially export a reusable networking API.
My August comment has the details.
Attachments
Issue Links
- blocks
-
MDEV-19248 Implement MASTER_BIND for CHANGE MASTER
-
- Stalled
-
- causes
-
MDEV-36812 Implement MYSQL_OPT_BIND
-
- Stalled
-
- is part of
-
MDEV-10900 change federateds, connect, and replication to use Connector/C
-
- Open
-
- relates to
-
MDEV-9295 Connector/C — embedded
-
- Open
-
-
MDEV-37531 Move Replication sources to an `rpl` directory
-
- Open
-
-
MDEV-9055 replace libmysqlclient with Connector/C
-
- Open
-