Exclude SELECT and INSERT SELECT from vers_set_hist_part(). We cannot
likewise exclude REPLACE SELECT because it may REPLACE into itself
(and REPLACE generates history).

INSERT also does not generate history, but we have history
modification setting which might be interfered.

Fix error code.

Adjust the test for full_crc32.

Problem:
========
Checksum for the encrypted temporary tablespace is not stored in the page
for full crc32 format.

Solution:
========
Made temporary tablespace in full crc32 format irrespective of encryption
parameter.

buf_tmp_page_encrypt(), buf_tmp_page_decrypt() - Both follows full_crc32
format.

This was broken in 2dbe472e

Fixed the following issues:
- Call info with HA_STATUS_CONST to ensure that (key_info->rec_per_key)
  contains latest data
- Don't access rec_per_key if key_info->algorithm == HA_KEY_ALG_LONG_HASH
  is in this case the rec_per_key points to uninitialized data
- Cleaned up code to avoid some extra 'if' and to make things more readable
- Updated test cases that used 'old' rec_per_key values

The names rows_for_plan and cost_for_plan follow MySQL
Also added post-join-operation selectivity cost

Starting with MDEV-12288 in MariaDB Server 10.3,
the transaction identifiers on records will be reset on purge.
Because purge might or might not run to completion before shutdown,
it could happen that the bogus transaction identifier that our
test is writing will be reset by purge after restart, and the
expected warning message on SELECT will fail to appear.

We resolve the race condition by ensuring that purge runs to
completion before the shutdown.

Use DEBUG_SYNC to hang the execution at the interesting point,
and then kill and restart the server externally. This will work
also with Valgrind. DBUG_SUICIDE() causes Valgrind to hang,
and it could also cause uninteresting reports about memory leaks.

While we are at it, let us clean up innodb.innodb_bulk_create_index_debug
so that it will actually test the desired functionality also in future
versions (with instant ADD COLUMN and DROP COLUMN) and avoid
some unnecessary restarts.

We are adding two DEBUG_SYNC points for ALTER TABLE, because there were
none that would be executed right before ha_commit_trans().

Galera threads were not registered to performance schema and
used pthread_create when mysql_thread_create should have been
used.

Added test case to verify current galera performance schema
instrumentation does work.

Test changes only.

Skip the test on big-endian systems.
In MariaDB Server 10.0 and 10.1 (as well as MySQL 5.6),
the implementation of innodb_checksum_algorithm=crc32
wrongly assumes little-endian byte order.

Fix incorrect else that should have been else if.

Starting with commit 210855ce
Valgrind became aware that the unused tail of the buffer that
is returned by thd_get_xid() is actually uninitialized.

The problem should exist already in MySQL 5.0. I was able to
repeat it on MariaDB Server 5.5 with some additional instrumentation.
InnoDB is allocating 128+4+4 bytes for the XID and the lengths of
its components, even when the XID is shorter than 64+64 bytes.
In MariaDB Server 10.3, while running the test main.xa_binlog,
in the xid_t::set() that is called by sql_yacc.yy, the 128-byte data
buffer was uninitialized according to Valgrind, and only the first bytes
were initialized. When the xid_t::data was copied to
thd.transaction.xid_state.xid.data, it happened so that the entire
target buffer was considered initialized. With MariaDB Server 10.4 since
the said commit, Valgrind will correctly be detect the tail of the buffer
as uninitialized.

The impact of this bug is as follows:

(1) InnoDB will write unnecessarily much redo log for XA PREPARE.
(2) InnoDB will write garbage bytes to the redo log and undo log pages.
(3) The garbage should be 'harmless', because on recovery, only the
actual payload of the XID will be used, based on the written length.

trx_rseg_write_wsrep_checkpoint(), trx_undo_write_xid(): Write only
the actually used length of xid->data to the data page, and
zero out the rest of the buffer by mlog_memset().

This fixes the following test failures related to index cardinality:
main.join main.stat_tables main.partition main.stat_tables_innodb
innodb.innodb_bug57252

MDEV-17614 flags INSERT…ON DUPLICATE KEY UPDATE unsafe for statement-based
replication when there are multiple unique indexes. This correctly fixes
something whose attempted fix in MySQL 5.7
in mysql/mysql-server@c93b0d9a972cb6f98fd445f2b69d924350f9128a
caused lock conflicts. That change was reverted in MySQL 5.7.26
in mysql/mysql-server@066b6fdd433aa6673622341f1a2f0a3a20018043
(with a substantial amount of other changes).

In MDEV-17073 we already disabled the unfortunate MySQL change when
statement-based replication was not being used. Now, thanks to MDEV-17614,
we can actually remove the change altogether.

This reverts commit 8a346f31 (MDEV-17073)
and mysql/mysql-server@c93b0d9a972cb6f98fd445f2b69d924350f9128a while
keeping the test cases.

- mysqltest didn't free read_command_buf
- wait_for_slave_param did write different things to the log if valgrind
  was used.
- Table open cache should not write the initial variable value as it
  can depend on the configuration or if valgrind is used
- A variable in GetResult was used uninitalized

- Initialize variables that could be used uninitialized
- Added extra end space to DbugStringItemTypeValue to get rid of warnings
  from c_ptr()
- Session_sysvars_tracker::update() accessed unitialized memory if called
  with NULL value.
- get_schema_stat_record() accessed unitialized memory if HA_KEY_LONG_HASH
  was used
- parse_vcol_defs() accessed random memory for tables without keys.

initialize_readline() is called with full pathname of executable which
sets rl_readline_name to that value.

It is expected that rl_readline_name is initialized with static name
not depending on the file name at all. Needed for setting custom
hotkeys in .inputrc

1. Fix DBUG_ASSERT(!table->pos_in_locked_tables) in tc_release_table();
2. Fix access of prematurely freed MDL_ticket: don't close ticket if table was not closed;
3. Fix deadlock after erroneous ALTER.

mysql_alter_table() leaves dirty table->m_needs_reopen in case of
error exit which then incorrectly treated by mysql_lock_tables().

Prevent conflicting clauses at parser level.

Clear HA_VERSIONED_TABLE flag for DROP SYSTEM VERSIONING (for the sake
of strictness).

Special case for DROP PERIOD when system fields are implicit.

For MODE_SIMULTANEOUS_ASSIGNMENT it is required to return back field
offsets from record[1] to record[0]. 'continue' in warning branch did
skip of rfield->move_field_offset() call.

Wrong value F_WRLCK for thr_lock_type.

Prune to now-partition when there is no FOR SYSTEM_TIME clause.

... produces "bytes lost" warnings

When rocksdb_validate_update_cf_options() returns an error,
the update won't happen.
Free the copy of the string in this case.

Problem:-
When mysql executes INSERT ON DUPLICATE KEY INSERT, the storage engine checks
if the inserted row would generate a duplicate key error. If yes, it returns
the existing row to mysql, mysql updates it and sends it back to the storage
engine.When the table has more than one unique or primary key, this statement
is sensitive to the order in which the storage engines checks the keys.
Depending on this order, the storage engine may determine different rows
to mysql, and hence mysql can update different rows.The order that the
storage engine checks keys is not deterministic. For example, InnoDB checks
keys in an order that depends on the order in which indexes were added to
the table. The first added index is checked first. So if master and slave
have added indexes in different orders, then slave may go out of sync.

Solution:-
Make INSERT...ON DUPLICATE KEY UPDATE unsafe while using stmt or mixed format
When there is more then one unique key.
Although there is two exception.
  1. Auto Increment key is not counted because Innodb will get gap lock for
    failed Insert and concurrent insert will get a next increment value. But if
    user supplies auto inc value it can be unsafe.
  2. Count only unique keys for which insertion is performed.

So this patch also addresses the bug id #72921