The limit of socket length on unix according to libc is 108, see
sockaddr_un::sun_path, but in the table it is a string of max length
64, which results in truncation of socket and failure to connect by
plugins using servers such as spider.
Some fixes related to commit f838b2d799 and
Rows_log_event::do_apply_event() and Update_rows_log_event::do_exec_row()
for system-versioned tables were provided by Nikita Malyavin.
This was required by test versioning.rpl,trx_id,row.
.. is not updating some system tables
Some schema changes from MDEV-24312 master_host has 60 character limit, increase to 255 bytes
failed to happen in the upgrade for tables in the mysql schema:
* mysql.global_priv
* mysql.procs_priv
* mysql.proxies_priv
* mysql.roles_mapping
Also in the startup, lets not "Error" on attempting to install a
mysql.plugin that is already there. We use the 'if_not_exists'
parameter to true to downgrade this to a "Note".
Also corrects: MDEV-32041 "plugin already loaded" should be a Warning, not an Error
The MDEV-29693 conflict resolution is from Monty, as well as is
a bug fix where ANALYZE TABLE wrongly built histograms for
single-column PRIMARY KEY.
Also includes a fix for safe_malloc error reporting.
Other things:
- Copied main.log_slow from 10.4 to avoid mtr issue
Disabled test:
- spider/bugfix.mdev_27239 because we started to get
+Error 1429 Unable to connect to foreign data source: localhost
-Error 1158 Got an error reading communication packets
- main.delayed
- Bug#54332 Deadlock with two connections doing LOCK TABLE+INSERT DELAYED
This part is disabled for now as it fails randomly with different
warnings/errors (no corruption).
The table structure from MySQL-5.1.14 is:
CREATE TABLE `slow_log` (
`start_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`user_host` mediumtext NOT NULL,
`query_time` time NOT NULL,
`lock_time` time NOT NULL,
`rows_sent` int(11) NOT NULL,
`rows_examined` int(11) NOT NULL,
`db` varchar(512) DEFAULT NULL,
`last_insert_id` int(11) DEFAULT NULL,
`insert_id` int(11) DEFAULT NULL,
`server_id` int(11) DEFAULT NULL,
`sql_text` mediumtext NOT NULL
) ENGINE=CSV DEFAULT CHARSET=utf8 COMMENT='Slow log'
Even as far back as MySQL-5.5.40 this table could be created as NULLs
where not permitted in the CSV table time, but it seems they
where allowed sometime.
As the first part of mariadb-upgrade adds the column thread_id without
correcting the 'NULL'able status of existing columns it fails.
We reorder the sql statements in the ugprade as follows:
ALTER TABLE slow_log MODIFY {columns} {new types} NOT NULL,....
As thread_id doesn't exist in the above statement it was removed from
the first ALTER TABLE statement to prevent failure.
Previous ALTER TABLE slow_log where moved later appending thread_id
and rows_affected, and also enforces the type of thread_id if it
was incorrectly like the now first ALTER STATEMENT slow_log used
to do.
mysql.proc. The table is probably corrupted"
Analysis: When mysql_upgrade runs statements for upgrade, characterset is
converted to utf8mb4 because server starts with old_mode that interprets
utf8 to utf8mb4, but mysql.proc table has "utf8mb3" as hardcoded, so
it crashes with corrupted table.
Fix: Changed Table_check_intact::check() definition to allow both
utf8mb3 and utf8mb4 by checking prefix and changing the upgrade scripts
to explicitly use utf8mb3
- Moved view checks after privilege tables are fixed. This is to avoid
warnings about wrongly defined mysql.proc when checking views.
- Don't use stat tables before they have been fixed.
- Don't run mysql_fix_view() if 'FOR MYSQL' is used if the view is
already a MariaDB view.
- Added 'FOR UPGRADE' as an option for 'REPAIR VIEW' to be able to
detect if the REPAIR command comes from mariadb_upgrade. In this
case we get a warning, instead of an error, if a definer of a view
does not exists.
Running mysql_upgrade should end up with the exact same system tables as fresh
installations have after running mysql_install_db. To ensure the upgrade is
correct and complete:
- Remove the redundant modification of thread_id`. On 5.5 version, the
`general_log` table was created as `CREATE TABLE IF NOT EXISTS general_log
(..., thread_id INTEGER NOT NULL, ...)`, and starting from 10.0+, the table is
created as `CREATE TABLE IF NOT EXISTS general_log (..., thread_id BIGINT(21)
UNSIGNED NOT NULL, ...)`, but mysql_upgrade is not properly upgrading the
table. It modifies the `thread_id` twice in one query, which could leave the
table not modified and lead to other potential error when upgrading from
MariaDB 5.5 or older.
- Update `servers` to ensure `Host` and `User` has correct data type if
upgrading from 10.1 or older. On versions 10.0 and 10.1, the `servers` table
was created as `CREATE TABLE IF NOT EXISTS servers (..., Host char(64) NOT
NULL DEFAULT , ..., Owner char(64) NOT NULL DEFAULT , ...)`, and starting
from 10.2, the table is created as `CREATE TABLE IF NOT EXISTS servers (...,
Host varchar(2048) NOT NULL DEFAULT , ..., Owner varchar(512) NOT NULL
DEFAULT , ...)`.
All new code of the whole pull request, including one or several files that
are either new files or modified ones, are contributed under the BSD-new license.
I am contributing on behalf of my employer Amazon Web Services, Inc.
MDEV-16735 describes how mysql_upgrade fails when alter_algorithm
is set to a value different than 'DEFAULT'/'COPY'. It was marked as
fixed by 0ee0868, but the fix didn't covered the possibility of having
the global value of alter_algorithm set to something different than
'DEFAULT'/'COPY'. To ensure that the upgrade process works properly
regardless the global value of alter_altorithm, this commit force it's
value to 'DEFAULT' (note the quotes) for the mysql_upgrade session.
All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license. I am contributing on behalf of my employer
Amazon Web Services, Inc.
Increasing the data type from char(32) to char(64) for
the following system columns:
- mysql.event.collation_connection
- mysql.event.db_collation
- mysql.proc.collation_connection
- mysql.proc.db_collation
This change was forgotten during MDEV-27009.
Also fixing the comment "Start/End of 10.9 tests" in ctype_utf8_uca.test
to "Start/End of 10.10 tests", as MDEV-27009 was actually
released in 10.10.
The incorrect type of mysql.column_stats caused the server during the
upgrade of every other table to complain:
[ERROR] Incorrect definition of table mysql.column_stats: expected column 'hist_type' at position 9
and expected column 'histogram' at position 10 to have type longblob.
To prevent these verbose server errors, we upgrade the
mysql.column_stats table first.
Consequently limit "Incorrect definition of table mysql.*" to the appropriate
set of limited test cases.
The rpl_gtid_errorhandling.result changes the GTID number by one
because of the added early suppression (adding a table row).
Reviewer: Vicențiu Ciorbaru
FixesMariaDB/mariadb-docker#438
from mysql.plugin table
Fix: Since mysql_upgrade runs commands from mysql_system_tables.fix,
added sql commands to check for semisync plugins in
INFORMATION_SCHEMA.PLUGINS and if they aren't there then delete them
from mysql.plugin.
