The remote users need the SUPER privilege because by default Spider sends a
'SET SQL_LOG_OFF' statement to the data nodes.  This is controlled by the
spider_internal_sql_log_off configuration setting on the Spider node, which
can only be set to 0 or 1, with a default value of 1.

I have fixed the problem by changing this configuration setting so that if it
is NOT SET, which is the most likely case, the Spider node DOES NOT SEND the
'SET SQL_LOG_OFF' statement to the data nodes.  However if the
spider_internal_sql_log_off setting IS EXPLICITLY SET to either 0 or 1, then
the Spider node DOES SEND the 'SET SQL_LOG_OFF' statement, requiring a remote
user with the SUPER privilege.  The Spider documentation will be updated to
reflect this change.

Author:
  Jacob Mathew.

Reviewer:
  Kentoku Shiba.

trx_undof_page_add_undo_rec_log(): Write the undo page number
directly from the buf_block_t descriptor, not by decoding the
fields in the page frame.

trx_undof_page_add_undo_rec_log(): Write the MLOG_UNDO_INSERT
record instead of the equivalent MLOG_2BYTES and MLOG_WRITE_STRING.
This essentially reverts commit 9ee8917d.

In MariaDB 10.3, I attempted to simplify the crash recovery code
by making use of lower-level redo log records. It turns out that
we must keep the redo log parsing code in order to allow crash-upgrade
from older MariaDB versions (MDEV-14848).

Now, it further turns out that the InnoDB redo log record format is
suboptimal for logging multiple changes to a single page. This simple
change to the redo logging of undo log significantly affects the
INSERT and UPDATE performance.

Essentially, we wrote
	(space_id,page_number,MLOG_2BYTES,2 bytes)
	(space_id,page_number,MLOG_WRITE_STRING,N+4 bytes)
instead of the previously written
	(space_id,page_number,MLOG_UNDO_INSERT,N+2 bytes)

The added redo log volume caused a single-threaded INSERT
(without innodb_adaptive_hash_index) of
1,000,000 rows to consume 11 seconds instead of 9 seconds,
and a subsequent UPDATE of 30,000,000 rows to consume 64 seconds
instead of 58 seconds. If we omitted all redo logging for the
undo log, the INSERT would consume only 4 seconds.

The trx_t::undo_mutex covered both some main-memory data structures
(trx_undo_t) and access to undo pages. The trx_undo_t is only
accessed by the thread that is associated with a running transaction.
Likewise, each transaction has its private set of undo pages.
The thread that is associated with an active transaction may
lock multiple undo pages concurrently, but no other thread may
lock multiple pages of a foreign transaction.

Concurrent access to the undo logs of an active transaction is possible,
but trx_undo_get_undo_rec_low() only locks one undo page at a time,
without ever holding any undo_mutex.

It seems that the trx_t::undo_mutex would have been necessary if
multi-threaded execution or rollback of a single transaction
had been implemented in InnoDB.

Use the value trx_undo_t::top_undo_no == IB_ID_MAX for indicating
that an undo log is empty.

rw_trx_hash_t::find(): Implement a fast path for looking up
the current transaction. This helps transactions that visit
rows modified by themselves.

In the merge of commit e7f4e61f
the call fil_flush_file_spaces(FIL_TYPE_LOG) is necessary.
Tablespaces will be flushed as part of the redo log
checkpoint, but the redo log will not necessarily
be flushed, depending on innodb_flush_method.

Related implementations.

InnoDB takes a lot of time to perform null updates. The reason is that
even though an empty update vector was created, InnoDB will go on to
write undo log records and update the system columns
DB_TRX_ID and DB_ROLL_PTR in the clustered index, and of course write
redo log for all this.

This could have been fixed properly in
commit 54a492ec more than 10 years ago.

- Removed never used warning that explicit_defaults_for_timestamp was
  not set

MDEV-15732: Assertion `next_free_value % real_increment == offset && next_free_value >= reserved_until' failed in sequence_definition::adjust_values upon SETVAL for sequence with INCREMENT 0

there was a problem with "next_free_value >= reserved_until" condition:
SEQUENCE::set_value handle next_free_value & reserved_until after adjust_values() call, so it is incorect to put assert on it in adjust_values()

Differences:

MariaDB doesn't support a JSON type therefore the crc32 on those values
are different.

JSON extract syntax is different.

loaddata_utf8 has 3 duplicate lines removed compared to MySQL version.

From mysql-server:
09fdfad50764ff6809e7dd5300e9ce1ab727b62a
e90ae1707e0ca46abc775d1680d1856c4be38b66

described in http://github.com/mysql/mysql-server/pull/157

Apart from external contribution I have added few more additional testcases
for CRC32() function, which are given below.

New Testcases added:
  ->Verify the crc value of various numeric and string data types(int,
      double, blob, text, json, enum, set)
  ->Verify the crc value when expressions having comparison_operators
      and logical_operators
  ->Verify the crc value for the expression having string_functions,
      arithmetic_functions, json_functions
  ->Verify the crc value for the expression having Geometry functions
      like POINT, LINESTRING, MULTILINESTRING, POLYGON, MULTIPOLYGON
  ->Verify the crc value generated from stored procedures, functions,
      triggers, prepare statement, views.

Fix:
Patch based on contribution by Daniel Black (Github user: grooverdan)

Reviewed-by: Anitha Gopi anitha.gopi@oracle.com
Reviewed-by: Srikanth B R srikanth.b.r@oracle.com

RB: 17294

Remove the local variable srv_buf_pool_size_org, which was always 0.
In MySQL 5.7, InnoDB was made a mandatory storage engine, which would
force InnoDB to start up when executing
	mysqld --verbose --help
which is what mysql-test-run.pl is doing as a first step. With a
large innodb_buffer_pool_size, this would take a long time.
So, MySQL 5.7 includes a hack that starts up InnoDB with a smaller
buffer pool when the option --verbose is present.

MariaDB uses HAVE_LZO, not HAVE_LZO1X (which was never defined).
Also, the variable srv_lzo_disabled was never defined or read
(only declared and assigned to, in unreachable code).

The InnoDB system table column SYS_TABLES.MIX_LEN was repurposed
in InnoDB Plugin for MySQL 5.1, in
commit 91111174 (MySQL 5.1.46).
Until MySQL 5.6, it only contained a flag DICT_TF2_TEMPORARY.

MySQL 5.6 introduced a number of flags that were transient
in nature. One of these was introduced in 5.6.5, originally
called DICT_TF2_USE_TABLESPACE and later renamed to
DICT_TF2_USE_FILE_PER_TABLE. MySQL 5.7.6 introduced logic
that insists that the flag be set for any table that does not
reside in a shared tablespace, breaking upgrade from MySQL 5.5.

MariaDB does not support shared tablespaces other than the
InnoDB system tablespace. Also, some dependencies on
SYS_TABLES.MIX_LEN were removed in an earlier fix:
MDEV-13084 MariaDB 10.2 crashes on corrupted SYS_TABLES.MIX_LEN field
(commit e813fe86).

dict_check_sys_tables(): Remove a bogus debug assertion, and add a
comment that explains how DICT_TF2_USE_FILE_PER_TABLE is used.

dict_table_is_file_per_table(): Remove a bogus debug assertion.

Added metadate info after prepare EXPLAIN/ANALYZE.

Switch off automatic INTERSECT  priority for ORACLE MODE

MDEV-15079: Parameter array operation inserts wrong values in autoincrement field if indicator was specified

test added (bug is fixed)

The field undo_rseg_space was only used in a debug check.

trx_roll_check_undo_rec_ordering(): Remove.

It has been done to demonstrate that the fix of this bug is good for 10.3
as well. The previous test case is not good for this purpose because
10.2 and 10.3 use different rules for determining the types of recursive
CTEs.

Pool::mem_free(): Poison the freed memory. Assert that it was
fully initialized, because the reuse of trx_t objects will
assume that the objects were previously initialized.

Pool::~Pool(), Pool::get(): Unpoison the allocated memory,
and mark it initialized.

trx_free(): After invoking Pool::mem_free(), unpoison
trx_t::mutex and trx_t::undo_mutex, because MutexMonitor
will access these even for freed trx_t objects.

Modern compilers (such as GCC 8) emit warnings that the
'register' keyword is deprecated and not valid C++17.

Let us remove most use of the 'register' keyword.
Code in 'extra/' is not touched.

Apply the contributed patch from
MySQL Bug #89126 create table panic on innobase_parse_hint_from_comment
by Yan Huang.

- Allow NOT NULL constraint to replace the NULL value in the row with
explicit or implicit default value.

- If the default value is non-const value then inplace alter won't
support it.

- ALTER IGNORE will ignore the error if the concurrent DML contains
NULL value.