The assertion was caused by use of operator[] for an empty vector.
The wsrep-lib update changes vector operations which access
the underlying data array to use data() method which is valid
for empty vectors.

Versioned conditions in on_expr can not be rebuilt at optimization
stage on non-conventional arena.

MDEV-17978 Server crash in SHOW CREATE SEQUENCE on a broken view

Incorrect assertion of EXTRA_CACHE for
HA_EXTRA_PREPARE_FOR_UPDATE. The latter is related to read cache, but
must operate without it as a noop.

Related to Bug#55458 and MDEV-20441.

In MariaDB 10.2 master could have been configured so that there
is extra annotate events. When we peak next event type for CTAS we
need to skip annotate events.

This patch contains two fixes:

* wsrep_handle_mdl_conflict(): handle the case where SR transaction
  is in aborting state. Previously, a BF-BF conflict was reported, and
  the process would abort.
* wsrep_thd_bf_abort(): do not restore thread vars after calling
  wsrep_bf_abort(). Thread vars are already restored in wsrep-lib if
  necessary. This also removes the assumption that the caller of
  wsrep_thd_bf_abort() is the given bf_thd, which is not the case.

Also in this patch:

* Remove unnecessary check for active victim transaction in
  wsrep_thd_bf_abort(): the exact same check is performed later in
  wsrep_bf_abort().
* Make wsrep_thd_bf_abort() and wsrep_log_thd() const-correct.
* Change signature of wsrep_abort_thd() to take THD pointers instead
  of void pointers.

Related to 87731177 and Bug#47649.

Don't set Query_arena::STMT_EXECUTED for any error
code. skip_setup_conds() depends on STMT_INITIALIZED_FOR_SP, but
sp_lex_keeper::reset_lex_and_exec_core() sets it to STMT_EXECUTED on
ER_TABLE_NOT_LOCKED_FOR_WRITE. There are other error codes that can
break skip_setup_conds() (ER_IT_IS_A_VIEW, ER_NON_UPDATABLE_TABLE,
etc).

Unit prepare prematurely fixed field which must be fixed via
setup_conds() to correctly update table->covering_keys.

Call vers_setup_conds() directly instead, because actually everything
else is not needed.

Unit prepare prematurely fixed field which must be fixed via
setup_conds() to correctly update table->covering_keys.

Call vers_setup_conds() directly instead, because actually everything
else is not needed.

Wrong assertion condition. SYSTEM_TIME_ALL indicates that
vers_setup_conds() is done. In case FOR SYSTEM_TIME ALL is specified
in command the assertion passes but not checks anything.

mlog_write_initial_log_record_low(): Do not allow the MLOG_TRUNCATE
record to be written.

Ensure that pointer to a buffer which is used for both reads and writes
is properly aligned.

I've intentially put permanent check right before io_submit() call instead
of the time of setting iocb date. I think that'll make check better.

LinuxAIOHandler::resever_slot(): check arguments alignment in debug builds

Add proper wsrep sync wait.

The function get_wkb_of_default_point() should never have been
added, and the cleanup in commit 56ff6f1b
should have removed it.

The unnecessary code was added in
mysql/mysql-server@0a27b72171c4449f506ad4e93df8c29fead1ed72
and mostly disabled in
mysql/mysql-server@8f11af7734509821b654f2c330dff5374c89073c.

In MariaDB, the types DATA_POINT and DATA_VAR_POINT are never used.
Instead, DATA_GEOMETRY continues to be used since 10.2.2, introduced by
mysql/mysql-server@673bad7c7e17701b69e29d0fbc4e2d68c1a7b613
in MySQL 5.7.1.

The lintian Debian tool is complaining about:
  'W: mariadb-test: manpage-has-errors-from-man
  usr/share/man/man1/mysql-test-run.pl.1.gz 246: warning [p 2, 6.0i, div
  '3tbd1,1', 0.3i]: can't break line'

See: https://salsa.debian.org/faust-guest/mariadb-10.3/-/jobs/431900

The following command permits to catch the problematic lines:
  $ groff -man -Tascii ./mysql-test-run.pl.1 | less

Closes #1419

Conflicts:
	mysql-test/suite/galera/t/galera_binlog_event_max_size_max-master.opt
	mysql-test/suite/innodb/r/innodb-mdev-7513.result
	mysql-test/suite/innodb/t/innodb-mdev-7513.test
	mysql-test/suite/wsrep/disabled.def
	storage/innobase/ibuf/ibuf0ibuf.cc

The script is intented to be sourced by other SST script so it should
not be executable (or should have a script header).
This is causing a warning on Debian Lintian tool, see:
https://salsa.debian.org/faust-guest/mariadb-10.3/-/jobs/431900

The lintian check complains on spelling error:
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/95739

Don't do skip_setup_conds() unless all errors are checked.

Fixes following errors:
      ER_PERIOD_NOT_FOUND
      ER_VERS_QUERY_IN_PARTITION
      ER_VERS_ENGINE_UNSUPPORTED
      ER_VERS_NOT_VERSIONED

Don't do skip_setup_conds() unless all errors are checked.

Fixes following errors:
      ER_PERIOD_NOT_FOUND
      ER_VERS_QUERY_IN_PARTITION
      ER_VERS_ENGINE_UNSUPPORTED
      ER_VERS_NOT_VERSIONED

MDEV-21011 Table corruption reported for versioned partitioned table after DELETE: "Found a misplaced row"

LIMIT history partitions cannot be checked by existing algorithm of
check_misplaced_rows() because working history partition is
incremented each time another one is filled. The existing algorithm
gets record and tries to decide partition id for it by
get_partition_id(). For LIMIT history it will just get first
non-filled partition.

To fix such partitions it is required to do REBUILD instead of REPAIR.

When view is merged by DT_MERGE_FOR_INSERT it is then skipped from
processing and doesn't update WHERE clause with
vers_setup_conds(). Note that view itself cannot work in
vers_setup_conds() because it doesn't have row_start, row_end
fields. Thus it is required to descend down to material TABLE_LIST
through calls of mysql_derived_prepare() and run vers_setup_conds()
from there. Luckily, all views (views of views, views of views of
views, etc.) are linked in one list through next_global pointer, so we
can skip all views of views and get straight to non-view TABLE_LIST by
checking its merge_underlying_list property for zero value (it is
assigned by DT_MERGE_FOR_INSERT for merged derived tables).

We have to do that only for UPDATE and DELETE. Other DML commands
don't use WHERE clause.

MDEV-21146 Assertion `m_lock_type == 2' in handler::ha_drop_table upon LOAD DATA

LOAD DATA does not use WHERE and the above call of vers_setup_conds()
is not needed. unit->prepare() led to wrongly locked temporary table.