MDEV-27068 running mariadb-upgrade in parallel make it hangs forever
MDEV-27107 prevent two mariadb-upgrade running in parallel
MDEV-27279 mariadb_upgrade add --check-if-upgrade-is-needed /
restrict tests to major version
Code is based of pull request from Daniel Black, but with a several
extensions.
- mysql_upgrade now locks the mysql_upgrade file with my_lock()
(Advisory record locking). This ensures that two mysql_upgrades
cannot be run in parallel.
- Added --check-if-upgrade-is-needed to mysql_upgrade. This will return
0 if one has to run mysql_upgrade.
Other changes:
- mysql_upgrade will now immediately exit if the major version and minor
version (two first numbers in the version string) is same as last run.
Before this change mysql_upgrade was run if the version string was different
from last run.
- Better messages when there is no need to run mysql_upgrade.
- mysql_upgrade --verbose now prints out a lot more information about
the version checking.
- mysql_upgrade --debug now uses default debug arguments if there is no
option to --debug
- "MySQL" is renamed to MariaDB in the messages
- mysql_upgrade version increased to 2.0
Notes
Verifying "prevent two mariadb-upgrade running in parallel" was
done in a debugger as it would be a bit complex to do that in mtr.
Reviewer: Danial Black <email address hidden>
d28d3ae...
by
Dmitry Shulga <email address hidden>
MDEV-24827: Follow-up patch to fix the test main.mysql_client_test_nonblock
MDEV-27544 database() function should return 64 characters
Database names are 64 utf8 characters per the system tables
that refer to them.
The current database() function is returning 34 characters.
The result of limiting this function results to max length of 34
became apparent when used in a UNION ALL where the results are
truncated to 34 characters.
For (uninvestigated) reasons, SELECT DATABASE() on its own
would always return the right number of characters.
810ef91...
by
Dmitry Shulga <email address hidden>
MDEV-24827: MariaDB 10.5.5 crash (sig 11) during a SELECT
Running a query using cursor could lead to a server crash on
building a temporary table used for handling the query.
For example, the following cursor
DECLARE cur1 CURSOR FOR
SELECT t2.c1 AS c1 FROM t1 LEFT JOIN t2 ON t1.c1 = t2.c1
WHERE EXISTS (SELECT 1 FROM t1 WHERE c2 = -1) ORDER BY c1;
declared and executed inside a stored routine could result in server
crash on creating a temporary table used for handling the ORDER BY clause.
Crash occurred on attempt to create the temporary table's fields based
on fields whose data located in a memory root that already freed.
It happens inside the function return_zero_rows() where the method
Select_materialize::send_result_set_metadata() is invoked for cursor case.
This method calls the st_select_lex_unit::get_column_types() in order to
get a list of items with types of columns for the temporary table being created.
The method st_select_lex_unit::get_column_types() returns
first_select()->join->fields
in case it is invoked for a cursor. Unfortunately, this memory has been already
deallocated bit earlier by calling
join->join_free();
inside the function return_zero_rows().
In case the query listed in the example is run in conventional way (without
using cursor) the method st_select_lex_unit::get_column_types()
returns first_select()->item_list that is not touched by invocation
of the method join->join_free() so everything is fine for that.
So, to fix the issue the resources allocated for the JOIN class should be
released after any activities with the JOIN class has been completed,
that is as the last statement before returning from the function
return_zero_rows().
This patch includes tests both for the case when a cursor is run explicitly
from within a stored routine and for the case when a cursor is opened
implicitly as prescribed by the STMT_ATTR_CURSOR_TYPE attribute of
binary protocol (the case of prepared statement).
