This test fails in case both embedded and PS mode are on.

A getsockopt level of 0 is requied on NetBSD when using
Unix-domain socket LOCAL_* options, SOL_SOCKET will not
work.

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)

It shouldn't be possible to install an old MariaDB-common
with a new MariaDB-server or vice versa.

returning NULL (a.k.a. nullptr) from a bool function.

followup for add782a1

because INSTALL_MYSQL_TEST() cmake macro has

      PATTERN "*.in" EXCLUDE

ha_innobase::can_switch_engines(): Use DBUG_RETURN instead of return
to match the DBUG_ENTER. This fixes a bootstrap failure of debug builds
using the default setting -DWITH_DBUG_TRACE=ON.

In commit 2647fd10 (MDEV-19445)
we fixed a race condition around the INFORMATION_SCHEMA tables
that access the table identified by the global variable
innodb_ft_aux_table. Thanks to MDEV-16678 we could fix it
even better by using MDL instead of the InnoDB dict_sys latches.

Before entering DML or DDL execution in the storage engine, the SQL layer
will have acquired metadata lock (MDL) on the current table name as well
as the names of FOREIGN KEY (grand)child tables (that is,
tables whose REFERENCES clauses point to the current table).
The MDL prevents any metadata changes to these tables, such as
RENAME, TRUNCATE, DROP, ALTER.

While the MDL on the current table prevents dict_table_t::foreign_set
from being modified, it does not prevent the table metadata that the
stored pointers are pointing to from being modified.

The MDL on the child tables will prevent both dict_table_t::referenced_set
as well as the pointed child table metadata from being modified.

wsrep_row_upd_index_is_foreign(): Do not unnecessarily acquire the
data dictionary latch if Galera replication is not enabled.

ha_innobase::can_switch_engines(): Rely on MDL. We are not dereferencing
any pointers stored in the sets.

row_mysql_freeze_data_dictionary(), row_mysql_unfreeze_data_dictionary():
Remove.

row_update_for_mysql(): Call init_fts_doc_id_for_ref() only once.

In ALTER TABLE...IMPORT TABLESPACE and FLUSH TABLES...FOR EXPORT
the SQL layer is protecting the current table with MDL. We do not
need InnoDB latches.

row_undo(): Remove the unnecessary acquisition and release of
dict_sys.latch. This was supposed to prevent the table from being
dropped while the undo log record is being rolled back. But, thanks to
trx_resurrect_table_locks() that was introduced in
mysql/mysql-server@935ba09d52c1908bde273ad1940b5ab919d9763d
and commit c291ddfd
as well as commit 1bd681c8
(MDEV-25506 part 3) tables will be protected against dropping
due to table locks.

This reverts commit 0049d5b5
(which had reverted a previous attempt of fixing this) and addresses
an earlier race condition with the following:

prepare_inplace_alter_table_dict(): If recovered transactions hold
locks on the table while we are executing online ADD INDEX, acquire
a table lock so that the rollback of those recovered transactions will
not interfere with the ADD INDEX.

The InnoDB internal SQL parser never supported this syntax.

Since commit 1bd681c8 tablespaces are
dropped after the table has been dropped. No dict_sys latch protection
is relevant during the execution of fil_delete_tablespace().

Since commit 1bd681c8
dict_stats_exec_sql() is no longer playing dirty tricks.
We can remove the workaround in lock_release().

fts_lock_table(): Fix a regression that was introduced in
commit da65cb4d (MDEV-25936).

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