The type uint16_t is apparently promoted to int in a comparison,
causing a sign mismatch when comparing to ulint. Convert to ulint
before comparison.

The type uint16_t is apparently promoted to int in a comparison,
causing a sign mismatch when comparing to ulint.
Convert both operands to uint16_t.

In online table-rebuilding ALTER TABLE (LOCK=NONE), virtual column values
are being written to the online_log. WL#8149 in MySQL 5.7 changed some
low-level functions that are also being used outside row0log.cc, causing
performance penalty to other code.

We revert those changes, and introduce separate functions for writing
the virtual column values.

The only functional change should be the one that is mentioned in
MDEV-13795: row_log_table_low_redundant() will no longer write
virtual column values along with old_pk, just like row_log_table_low().

As noted in MDEV-13795, some forms of table-rebuilding ALTER with
virtual columns is broken. At least DROP PRIMARY KEY, ADD PRIMARY KEY
is broken.

rec_get_converted_size_temp(), rec_convert_dtuple_to_temp():
Remove the parameter for passing virtual column values.

rec_get_converted_size_temp_v(), rec_convert_dtuple_to_temp_v():
New functions for appending virtual column values to the online_log.

rec_get_converted_size_comp_prefix_low(),
rec_convert_dtuple_to_rec_comp(): Remove the v_entry parameter,
and do not allow n_fields=0.

The InnoDB purge subsystem can be best stopped by opening a read view,
for example by START TRANSACTION WITH CONSISTENT SNAPSHOT.

To ensure that everything is purged, use wait_all_purged.inc,
which waits for the History list length in SHOW ENGINE INNODB STATUS
to reach 0. Setting innodb_purge_run_now never guaranteed this.

This also avoids hitting the hang at server shutdown.
That hang should be fixed, of course.

        set_charset() calls added for Item_func_json_arran
        and Item_func_json_object::val_str-s.

        Set default charset for temporary paths so UDF call don't crash.

        JSON_QUOTE return type set to be JSON.

        Tests added.

        '=0' added to meke the compiler happy.

        An extra ',' added to the JSON_MERGE result making it invalid.

        Superfluous ',' was added to the JSON_SET result so it became
        invalid.

Part#2: stabilize the test output

        Condition was fixed.

This fixes several InnoDB bugs related to innodb_encrypt_log and
two Mariabackup --backup bugs.

log_crypt(): Properly derive the initialization vector from the
start LSN of each block. Add a debug assertion.

log_crypt_init(): Note that the function should only be used when
creating redo log files and that the information is persisted in
the checkpoint pages.

xtrabackup_copy_log(): Validate data_len.

xtrabackup_backup_func(): Always use the chosen checkpoint buffer.

log_group_write_buf(), log_write_up_to(): Only log_crypt() the redo
log payload, not the padding bytes.

innobase_start_or_create_for_mysql(): Do not invoke log_crypt_init()
or initiate a redo log checkpoint.

recv_find_max_checkpoint(): Return the contents of LOG_CHECKPOINT_NO
to xtrabackup_backup_func() in log_sys->next_checkpoint_no.

        Implementation for the reverse spatial predicates was lost
        somehow.

        Let's check the validity to the end of the JSON.

Implement lock-ddl-per-table option that locks tables before it
is copied to backup, and helds the lock until backup finished

The "DDL-lock" itself is implemented as "SELECT * from <table> LIMIT 0",
inside a transaction, and "COMMIT" of this transaction is the DDL-unlock.

Now we allow derived in the from clause of subqueries so set
flag which prevent optimisation of subqueries during view
creation before derived processing so subquery will be
correctly printed in the view .frm.

If the method SELECT_LEX::mark_const_derived() is called for a select
that is used in the specification of a materialized derived table / view D
then method should not set the flag fill_me for D on when
the flag JOIN::with_two_phase_optimization is set on for this select.

This patch corrects the code of the patch for mdev-13369 that
introduced the splitting technique when using materialized
derived tables / views with GROUP BY. The second actual parameters
of the call of the method JOIN::reoptimize() in the function
JOIN::push_splitting_cond_into_derived() was calculated incorrectly.
This could cause different failures for queries using derived tables
or views with GROUP BY when their FROM lists contained empty or
single-row tables.

Currently condition pushdown into materialized views / derived tables
is not implemented yet (see mdev-12387) and grouping views are
optimized early when subqueries are converted to semi-joins in
convert_join_subqueries_to_semijoins(). If a subquery that is converted
to a semi-join uses a grouping view this view is optimized in two phases.
For such a view V only the first phase of optimization is done after
the conversion of subqueries of the outer join into semi-joins.
At the same time the reference of the view V appears in the join
expression of the outer join. In fixed code there was an attempt to push
conditions into this view and to optimize it after this. This triggered
the second phase of the optimization of the view and it was done
prematurely. The second phase of the optimization for the materialized
view is supposed to be called after the splitting condition is pushed
into the view in the call of JOIN::improve_chosen_plan for the outer
join.

The fix blocks the attempt to push conditions into splittable views
if they have been already partly optimized and the following
optimization for them.

The test case of the patch shows that the code for mdev-13369
basically supported the splitting technique for materialized views /
derived tables.

The patch also replaces the name of the state JOIN::OPTIMIZATION_IN_STAGE_2
for JOIN::OPTIMIZATION_PHASE_1_DONE and fixes a bug in
TABLE_LIST::fetch_number_of_rows()

trx_undo_assign_undo(): Restore the fault injection.

Import the test innodb.alter_crash

The redo log is divided into 512-byte blocks. Sometimes, some of
the strings end up at a block boundary and will not be found.
Look for only one match.

full server recovery is performed .
We start "mysqld" with  --bootstrap
and pass bootstrap script consisting of several FLUSH TABLES FOR export/
UNLOCK TABLES

recv_reset_logs(): Initialize the redo log buffer, so that no data
from the old redo log can be written to the new redo log.

This bug has very little impact before MariaDB 10.2. The
innodb_log_encrypt option that was introduced in MariaDB 10.1
increases the impact. If the redo log used to be encrypted, and
it is being resized and encryption disabled, then previously
encrypted data could end up being written to the new redo log
in clear text. This resulted in encryption.innodb_encrypt_log
test failures in MariaDB 10.2.

The SEARCH_ABORT logic was not working as intended
(tests were not being aborted).