ratzpo can you work on this for 10.5 now?

elenst Do you want to review this? It includes changes to error files and [test].result files because of the changed error text. The latest commit is 46ab6b1. I pushed it also to bb-10.5-release to get it tested a little broader.

Hi ratzpo,

Here are my notes.

More error message files

There is at least one more error message file, the one in the connector: libmariadb/libmariadb/ma_errmsg.c
It accounts for many remaining MySQL references:

mysql-test/main/crash_commit_before.result:ERROR HY000: Lost connection to MySQL server during query

mysql-test/main/delayed.result:ERROR HY000: Lost connection to MySQL server during query

mysql-test/main/myisam_crash_before_flush_keys.result:ERROR HY000: Lost connection to MySQL server during query

mysql-test/main/ssl_timeout.result:ERROR HY000: Lost connection to MySQL server during query

...

Maybe you changed it and the new submodule version is supposed to get pulled with the server, but it didn't for me when I cloned your branch.

Suppressions

There are still suppressions in MTR files which reference MySQL. Possibly many of those suppressions aren't needed at all, but removing them should a separate task. Meanwhile they need to be synchronized with the error messages, as some of them can be there to prevent irrelevant sporadic failures (and thus might not show up in test results right away).

./suite/galera_sr/r/galera_sr_mysqldump_sst.result:CALL mtr.add_suppression("Slave SQL: Error 'The MySQL server is running with the --skip-grant-tables option so it cannot execute this statement' on query");

include/mtr_warnings.sql: (": The MySQL server is running with the --secure-backup-file-priv option so it cannot execute this statement"),

Disabled tests

Some disabled tests still have the old messages. It's not critical, as whoever re-enables them is supposed to check the result file, but probably it makes sense to update them when possible and easy. Of course it's doesn't concern tests which are disabled because they are MySQL-specific, but remain in MariaDB code on whatever reason.

./suite/rpl/r/rpl_spec_variables.result:ERROR 42000: The used command is not allowed with this MySQL version

Error messages inside the code

There are error messages which are composed in the code directly, particularly (but probably not only) in replication. At the very least they can appear in error logs or stderr, but possibly they can also be added to SQL errors with generic patterns, like errors passed through from an engine.

Examples:

client/mysql_upgrade.c:    print_error("Version check failed. Got the following error when calling "

client/mysql_upgrade.c-                "the 'mysql' command line client", &ds_version);

sql/slave.cc:      errmsg= "The slave I/O thread stops because master and slave have equal \

sql/slave.cc-MySQL server ids; these ids must be different for replication to work (or \

sql/slave.cc-  rli->report(ERROR_LEVEL, ER_SLAVE_RELAY_LOG_READ_FAILURE, NULL,

sql/slave.cc-              ER_THD(thd, ER_SLAVE_RELAY_LOG_READ_FAILURE), "\

sql/slave.cc-Could not parse relay log event entry. The possible reasons are: the master's \

sql/slave.cc-binary log is corrupted (you can check this by running 'mysqlbinlog' on the \

sql/slave.cc-binary log), the slave's relay log is corrupted (you can check this by running \

sql/slave.cc:'mysqlbinlog' on the relay log), a network problem, or a bug in the master's \

sql/slave.cc-or slave's MySQL code. If you want to check the master's binary log or slave's \

sql/slave.cc-relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' \

and then the corresponding test results will have to be updated, e.g.

./suite/rpl/r/rpl_server_id1.result:Last_IO_Error = 'Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids; these ids must be different for replication to work (or the -

Generic vs specific

As I understand, this change

-  "MySQL server has gone away",

+  "Server has gone away",

comes from the discussion that the client cannot know which server it connects to. It is true, but then it should be the same for all hardcoded client errors referencing the server – "Unknown MariaDB server host", "Lost connection to MariaDB server during query", etc. wlad, what do you think? (since you raised this inaccuracy first, if I remember correctly)

TokuDB (side note)

There are probably many tests under TokuDB which will start failing; since we don't build TokuDB anymore, it isn't important. However, it raises the question whether it's okay to have in the code tests which will inevitably fail.

Yes, I think it is better not to use "MySQL" or "MariaDB" server in the error message, unless it is absolutely known it is MySQL or MariaDB or Percona, or something emulating one of those in AWS or Azure.
Also, it might be good time to reconsider using "mysqld --thread-stack" etc in messages. Rather than changing this mechanically to "mariadbd --thread-stack", I think it is better to advise, for example, to increase the thread-stack variable. Whether it is done in my.ini or my.cnf or via command line parameter, or at runtime, via SET GLOBAL does not matter. I'd guess changing this via command line parameter is not used as often as my.ini/.cnf.

Also stuff like "execute mysqladmin flush-hosts" does not have to remain in this form. FLUSH HOSTS is a normal command, which can be send via normal client´, or not?

There has been pushes relating to this issue:
0eab87c MDEV-22010: Allow mariadbd in mtr suppressions
d848fca MDEV-22010: mtr, "mariadbd" exists in mysys error messages
dcc2eae MDEV-22010: mtr search for mariadbd first

From elenst comment the following parts have been turned into their own issues:

• More error message files, CONC-466
• Suppressions, MDEV-22188
• Error messages inside the code, MDEV-22189