maria:bb-11.2-mdev-31524

Last commit made on 2023-07-13
Get this branch:
git clone -b bb-11.2-mdev-31524 https://git.launchpad.net/maria

Branch merges

Branch information

Name:
bb-11.2-mdev-31524
Repository:
lp:maria

Recent commits

cdc26cc... by Yuchen Pei <email address hidden>

MDEV-31524 Fixing spider table param / variable overriding

The existing (incorrect) overriding mechanism is:

Non-minus-one var value overrides table param overrides default value.

Before MDEV-27169, unspecified var value is -1. So if the user sets
both the var to be a value other than -1 and the table param, the var
value will prevail, which is incorrect.

After MDEV-27169, unspecified var value is default value. So if the
user does not set the var but sets the table param, the default value
will prevail, which is even more incorrect.

This patch fixes it so that table param, if specified, always
overrides var value, and the latter if not specified or set to -1,
falls back to the default value

We achieve this by replacing all such overriding in spd_param.cc with
macros that override in the correct way, and removing all the
"overriding -1" lines involving table params in
spider_set_connect_info_default() except for those table params not
defined as sysvar/thdvar in spd_params.cc

We also introduced macros for non-overriding sysvar and thdvar, so
that the code is cleaner and less error-prone

In server versions where MDEV-27169 has not been applied, we also
backport the patch, that is, replacing -1 default values with real
default values

In server versions where MDEV-28006 has not been applied, we do the
same for udf params

584c235... by Andrew Hutchings

MDEV-15736 Remove mariadb-admin --vertical

The `--vertical` option does not appear to behave as documented and
research shows it never appears to have behaved as intended.

As this appears to be a completely unused feature, let's remove it.

b8c039f... by Sergei Golubchik

MDEV-30188: fixes for 32-bit

a63c558... by Robin Newhouse <email address hidden>

Implement mysql_upgrade upgrade testing in CI

Performs an upgrade of mariadb from an earlier version to the rpms built
in CI. Then checks whether log contains evidence of upgrade in the form
of "Needs upgrade" or "Table rebuild required". Designed to check minor
version upgrades which should not trigger rebuilds.

The test is written in bash script so it can be executed from other CI
systems.

$ test_upgrade.sh source_version target_version
$ test_upgrade.sh source_version # defaults to rpm/
$ test_upgrade.sh source_version --rpm-dir <directory>

Binaries must be created with performance schema enabled, or
mysql_upgrade complains about missing tables.

Upgrade testing is parallelized with a "matrix" of source versions.
Others can be introduced later.

This was partially designed to catch issues like that seen in
https://jira.mariadb.org/browse/MDEV-28727 where a minor version upgrade
(e.g. 10.4.8 -> 10.4.26) triggered a system table rebuild.

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.

9b431d7... by Yuchen Pei <email address hidden>

MDEV-26137 Improve import tablespace workflow.

Allow ALTER TABLE ... IMPORT TABLESPACE without creating the table
followed by discarding the tablespace.

That is, assuming we want to import table t1 to t2, instead of

CREATE TABLE t2 LIKE t1;
ALTER TABLE t2 DISCARD TABLESPACE;
FLUSH TABLES t1 FOR EXPORT;
--copy_file $MYSQLD_DATADIR/test/t1.cfg $MYSQLD_DATADIR/test/t2.cfg
--copy_file $MYSQLD_DATADIR/test/t1.ibd $MYSQLD_DATADIR/test/t2.ibd
UNLOCK TABLES;
ALTER TABLE t2 IMPORT TABLESPACE;

We can simply do

FLUSH TABLES t1 FOR EXPORT;
--copy_file $MYSQLD_DATADIR/test/t1.cfg $MYSQLD_DATADIR/test/t2.cfg
--copy_file $MYSQLD_DATADIR/test/t1.frm $MYSQLD_DATADIR/test/t2.frm
--copy_file $MYSQLD_DATADIR/test/t1.ibd $MYSQLD_DATADIR/test/t2.ibd
UNLOCK TABLES;
ALTER TABLE t2 IMPORT TABLESPACE;

We achieve this by creating a "stub" table in the second scenario
while opening the table, where t2 does not exist but needs to import
from t1. The "stub" table is similar to a table that is created but
then instructed to discard its tablespace.

We include tests with various row formats, encryption, with indexes
and auto-increment.

b7ee3c7... by Marko Mäkelä

Merge 11.1 into 11.2

cee9b3b... by Marko Mäkelä

Merge 11.0 into 11.1

a906046... by Marko Mäkelä

Merge 10.11 into 11.0

3430767... by Marko Mäkelä

Merge 10.10 into 10.11

c2d5523... by Marko Mäkelä

Merge 10.9 into 10.10