InnoDB DDL fails when it tries to sync the table
when innodb_force_recovery is set to 2. Problem
is that fts_optimize_wq is not initialized when
there are no background threads. fts_sync_during_ddl()
should check whether fts_optimize_wq is initialized.

Fix for previous commit, shell logic for repeat configure
stages corrected to use subshell.

Columnstore badly failed on 32bit. The way Debian triggers
somehow doesn't detect the amd64 in the architecture of columnstore
so we explicitly disable it to prevent failures on x86_32.

The architecture from the control file is sufficient to not build
of arm64 and other unsupported achitectures so we don't need to
disable columnstore by default.

The logic around not building columnstore on Travis/Gitlab ci
can be preserved with a autobake-deb.sh restructure.

https://github.com/wolfSSL/wolfssl/issues/2828 lists 4.6.0 a
as the fixed version as we currently have 4.8.0.

Since the time of the above issue, Debian has allowed OpenSSL
linking.

This was a regression introduced in MDEV-18353, where to CONNECT objects
were incorrectly counted for named pipes.

Add server functions to provide necessary data.

The call to the function fts_check_corrupt() was removed
in commit 09af00cb already.

Server crashes in Field::register_field_in_read_map upon select from
partitioned table with indexed by prefix virtual column.

After several read-mark fixes a problem has surfaced:
Since KEY (c(10),a) uses only a prefix of c, a new field is created,
duplicated from table->field[3], with a new length. However,
vcol_inco->expr is not copied.

Therefore, (*key_info)->key_part[i].field->vcol_info->expr was left NULL
in ha_partition::index_init().

Solution: copy vcol_info from table field when it's set up.

This reverts commit 9b8e207c.

according to MDEV-17550 it's informational, not fatal.
"last committed" is part of the certification index purge process.

depending on what tests and in what order are run it can be triggered
at unspecified times during the testing. If the test is happen to
shut down the server at this very time, the log will have:

[Warning] WSREP: Failed to report last committed XXXYYYZZZ, -77 (File descriptor in bad state)

fix main.processlist_notembedded test

* before EXPLAINing `select sleep` wait for select to start
  (fixes "Target is not running an EXPLAINable command")
* after killing sleep, wait for it to die
  (fixes test failures on --repeat when old sleep shows on a test rerun)

* unify with 10.3, copy minor changes from there
  (`--echo End of 5.5` vs `--echo # End of 5.5`, etc)

len was containing garbage, since vctempl->mysql_col_offset was
containing old value while calling row_mysql_store_col_in_innobase_format
from innobase_get_computed_value().

It was not updated after the first ALTER TABLE call, because it's INPLACE
logic considered there's nothing to update, and exited immediately from
ha_innobase::inplace_alter_table().

However, vcol metadata needs an update, since vcols structure is changed
in mysql record.

The regression was introduced by 12614af1. There, refcount==1 condition
was removed, which turned out to be crucial, though racy. The idea was to
update vc_templ after each (sequencing) ALTER TABLE.

We should do the same another way, and there may be a plenty of solutions,
but the simplest one is to add a following condition:
  if vcol structure is changed, drop vc_templ; it will be recreated on next
  ha_innobase::open() call.

in prepare_inplace_alter_table. It is safe, since innodb inplace changes
require at least HA_ALTER_INPLACE_SHARED_LOCK_AFTER_PREPARE, which
guarantee MDL_EXCLUSIVE on this stage.

alter_templ_needs_rebuild() also has to track the columns not indexed, to
keep vc_templ correct.

Note that vc_templ is always kept constructed and available after
ha_innobase::open() call, even on INSERT, though no virtual columns are
evaluated during that statement
inside innodb.

In the test case suplied, it will be recreated on the second ALTER TABLE.

ha_innobase::prepare_inplace_alter_table(): Remove always-true conditions.
Near the start of the function, we would already have returned if
no ALTER TABLE operation flags were set that would require special
action from InnoDB.

It turns out that the conditions were redundant already when they were
introduced in mysql/mysql-server@241387a2b6b61fb8a4f78dc4ad0aaa289400c694
and in commit 068c6197.

Thanks to Nikita Malyavin for noticing this.

When creating fields for UNION results, Field_null is not allowed.
Should create binary(0) instead.

Pass char* to WSREP_LOG and others, instead of non-POD objects

from gamma

update libmarias3 to get the fix

Add a couple of NO_XXX prprocessor constants to wolfssl build.
Looked into cmake defaults, those are set there too. Some of
these are (supposedly) weak ciphers, and some just fallen out from wide
use.

This patch fixes the bug that TRIM(BOTH ... FROM $str), TRIM(LEADING ... FROM $str),
and TRIM(TRAILING ... FROM $str) failed with errors when executing on Spider.

Victim threads which are in currently in process of aborting or already
aborted should be skipped for another kill process.
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

MDEV-25740 Assertion `!wsrep_has_changes(thd) || (thd->lex->sql_command == SQLCOM_CREATE_TABLE && !thd->is_current_stmt_binlog_format_row())' failed in void wsrep_commit_empty(THD*, bool)

Using ROLLBACK with `completion_type = CHAIN` result in start of
transaction and implicit commit before previous WSREP internal data is
cleared.
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

MDEV-22421 Galera assertion !wsrep_has_changes(thd) || (thd->lex->sql_command == SQLCOM_CREATE_TABLE && !thd->is_current_stmt_binlog_format_row())

Updates to transaction registry table shouldn't be replicated in
cluster so there is no need to append wsrep keys.
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

Server crashes in Field::register_field_in_read_map upon select from
partitioned table with indexed by prefix virtual column.

After several read-mark fixes a problem has surfaced:
Since KEY (c(10),a) uses only a prefix of c, a new field is created,
duplicated from table->field[3], with a new length. However,
vcol_inco->expr is not copied.

Therefore, (*key_info)->key_part[i].field->vcol_info->expr was left NULL
in ha_partition::index_init().

Solution: initialize vcols before key initialization

Also key initialization is moved to a function.

Thanks to Nikita Malyavin for noticing this.
The dead code that was originally introduced in
mysql/mysql-server@b8bd31740cd7088f3a3c164981c7ccda487d301d
was added in commit 2e814d47
to this code base.

rename files `version` -> `version_full`

FetchIndexRootPages::operator(): handle REDUNDANT vs DYNAMIC case specifically.
Other combinations seems fine as is.