ha_innobase::get_auto_increment(): In the overflow check, account
for 64-bit unsigned integer wrap-around.

Based on mysql/mysql-server@25ecfe7f49b5a649e96d462cb90602de9de3b919

buf_flush_page(): Never wait for a page latch, even in checkpoint
flushing (flush_type == BUF_FLUSH_LIST), to prevent a hang of the
page cleaner threads when a large number of pages is latched.

In mysql/mysql-server@9542f3015b00330ef537f6223565b28b82a5b325
it was claimed that such a hang only affects CREATE FULLTEXT INDEX.
Their fix was to retain buffer-fix but release exclusive latch
on non-leaf pages, and subsequently write to those pages while
they are not associated with the mini-transaction, which would
trip a debug assertion in the MariaDB version of
mtr_t::memo_modify_page() and cause potential corruption
when using the default MariaDB setting innodb_log_optimize_ddl=OFF.

This change essentially backports a small part of
commit 7cffb5f6 (MDEV-23399)
from MariaDB Server 10.5.7.

Two bugs here:

1. CHECKSUM TABLE asserted that all fields in the table are arranged
   sequentially in the record, but virtual columns are always at the
   end, violating this assertion
2. virtual columns were not calculated for CHECKSUM, so CHECKSUM
   was using, essentially, garbage left from the previous statement.
   (that's why the test must use INSERT IGNORE to have this "previous
   statement" mark vcols not null)

Fix: don't include virtual columns into the table CHECKSUM. Indeed,
they cannot be included as the engine does not see virtual columns,
so in-engine checksum cannot include them, meaning in-server checksum
should not either

*again* after 388032e9 has reverted 25ccf8f6 by mistake

MDEV-25317 Assertion `scale <= precision' failed in decimal_bin_size And Assertion `scale >= 0 && precision > 0 && scale <= precision' failed in decimal_bin_size_inline/decimal_bin_size.

Precision should be kept below DECIMAL_MAX_SCALE for computations.
It can be bigger in Item_decimal. I'd fix this too but it changes the
existing behaviour so problemmatic to ix.

A result file is updated in one case and former error simulation got
refined.

The cause of crash:
remove_redundant_subquery_clauses() removes redundant item expressions.
The primary goal of this is to remove the subquery items.
The removal process unlinks the subquery from SELECT_LEX tree, but does
not remove it from SELECT_LEX:::ref_pointer_array or from JOIN::all_fields.
Then, setup_subquery_caches() tries to wrap the subquery item in an
expression cache, which fails, the first reason for failure being that
the item doesn't have a query plan.

Solution: do not wrap eliminated items with expression cache.
(also added an assert to check that we do not attempt to execute them).

This may look like an incomplete fix: why don't we remove any mention
of eliminated item everywhere? The difficulties here are:
* items can be "un-removed" (see set_fake_select_as_master_processor)
* it's difficult to remove an element from ref_pointer_array: Item_ref
objects refer to elements of that array, so one can't shift elements in
it. Replacing eliminated subselect with a dummy Item doesn't look like a
good idea, either.

upon HANDLER READ

Analysis: The error state is not stored while checking condition and key
name.
Fix: Return true while checking condition and key name if error is reported
because geometry object can't be created from the data in the index value
for HANDLER READ.

to detect the end of SP definition correctly we need to know where
the parser stopped parsing the SP. lip->get_cpp_ptr() shows the
current parsing position, lip->get_cpp_tok_start() shows the start of
the last parsed token. The actual value depends on whether
the parser has performed a look-ahead. For example, in

  CREATE PROCEDURE ... BEGIN ... END ;

the parser reads 'END' and knows that this ends the procedure definition,
it does not need to read the next token for this. But in

  CREATE PROCEDURE ... SELECT 1 ;

the parser cannot know that the procedure ends at '1'. It has to read
the semicolon first (it could be '1 + 2' for example).

In the first case, the "current parsing position" is after END, before
the semicolon, in the second case it's *after* the semicolon. Note that
SP definition in both cases ends before the semicolon.

To be able to detect the end of SP deterministically, we need the parser
to do the look-ahead always or never.

The bug fix introduces a new parser token FORCE_LOOKAHEAD. Lexer never
returns it, so this token can never match. But the parser cannot know
it so it will have to perform a look-ahead to determine that the next
token is not FORCE_LOOKAHEAD. This way we deterministically end
SP parsing with a look-ahead.

test only

This reverts commit 5ba77222
but keeps the test. A different fix for

MDEV-21028 Server crashes in Query_arena::set_query_arena upon SELECT from view

internal temporary tables should use THD as expr_area

This bug could cause a crash of the server at the second call of a stored
procedure when it executed a query containing a mergeable derived table /
view whose specification used another mergeable derived_table or view and a
subquery with outer reference in the select list of the specification.
Such queries could cause the same problem when they were executed for the
second time in a prepared mode.
The problem appeared due to a typo mistake in the legacy code of the function
create_view_field() that prevented building Item_direct_view_ref wrapper
for the mentioned outer reference at the second execution of the query and
setting the depended_from field for the outer reference.

Approved by Oleksandr Byelkin <sanja@mariadb.com>

In cases of a faulty master or an incorrect binlog event producer, that slave is working with,
sends an incomplete group of events slave must react with an error to not to log
into the relay-log any new events that do not belong to the incomplete group.

Fixed with extending received event properties check when slave connects to master
in gtid mode.
Specifically for the event that can be a part of a group its relay-logging is
permitted only when its position within the group is validated.
Otherwise slave IO thread stops with ER_SLAVE_RELAY_LOG_WRITE_FAILURE.

MDEV-28405 main.information_schema_tables fails sporadically with ER_NEED_REPREPARE or extra warning

The server behaves differently on the DATA/INDEX DIRECTORY clause
under valgrind because symlink is disabled under valgrind.

The --skip-write-binlog message was confusing that it only had
an effect if the galera was enabled. There are uses beyond galera
so we apply SET SESSION SQL_LOG_BIN=0 as implied by the option
without being conditional on the wsrep status.

Remove wsrep.mysql_tzinfo_to_sql_symlink{,_skip} tests as they offered
no additional coverage beyond main.mysql_tzinfo_to_sql_symlink as no
server testing was done.

Introduced a variant of the galera.mariadb_tzinfo_to_sql as
galera.mysql_tzinfo_to_sql, which does testing using the mysql client
rather than directly importing into the server via mysqltest.

Update man page and mysql_tzinfo_to_sql to having a --skip-write-binlog
option.

merge notes:
10.4:
- conflicts in tztime.cc can revert to this version of --help text.
- tztime.cc - merge execute immediate @prep1, and leave %s%s trunc_tables, lock_tables
  after that.
10.6:
- Need to remove the not_embedded.inc in mysql_tzinfo_to_sql.test and
  replace it with no_protocol.inc
- leave both mysql_tzinfo_to_sql.test and mariadb_tzinfo_to_sql.sql
  tests.
- sql/tztime.cc - keep entirely 10.6 version.

Added checking for support of vfork by a platform where
building being done. Set HAVE_VFORK macros in case vfork()
system call is supported. Use vfork() system call if the
macros HAVE_VFORK is set, else use fork().

When single-row subquery fails with "Subquery reutrns more than 1 row"
error, it will raise an error and return NULL.

On the other hand, Item_singlerow_subselect sets item->maybe_null=0
for table-less subqueries like "(SELECT not_null_value)"  (*)

This discrepancy (item with maybe_null=0 returning NULL) causes the
code in Type_handler_decimal_result::make_sort_key_part() to crash.

Fixed this by allowing inference (*) only when the subquery is NOT a
UNION.

MDEV-25243 ASAN heap-use-after-free in Item_func_sp::execute_impl upon concurrent view DDL and I_S query with view and function

if the view has algorithm=temptable it is not updatable,
so DEFAULT() for its fields is meaningless,
and thus it's NULL or 0/'' for NOT NULL columns.

because CONTEXT_ANALYSIS_ONLY_VCOL_EXPR can be used only for,
exactly, context analysys. Items fixed that way cannot be evaluated.
But vcols are going to be evaluated, so they have to be fixed properly,
for evaluation.

add test

Starting with 10.3, an assertion would fail on the rollback of
a recovered incomplete transaction if a table definition violates
a FOREIGN KEY constraint.

DICT_ERR_IGNORE_RECOVER_LOCK: Include also DICT_ERR_IGNORE_FK_NOKEY
so that trx_resurrect_table_locks() will be able to load
table definitions and resurrect IX locks. Previously, if the
FOREIGN KEY constraints of a table were incomplete, the table
would fail to load until rollback, and in 10.3 or later an assertion
would fail that the rollback was not protected by a table IX lock.

Thanks to commit 9de2e60d there
will be no problems to enforce subsequent FOREIGN KEY operations
even though a table with invalid REFERENCES clause was loaded.

Removed prohibition of creating temporary field of Item_default_value
(added by mistake by 1d9b043a fix of
MDEV-10780 and MDEV-11265).

When fixing vcols, fix_fields might call convert_const_to_int().
And that will try to read the field value (from record[0]).
Mark the table as having no data to prevent that, because record[0]
is not initialized yet.

the bug was that in_vector array in Item_func_in was allocated in the
statement arena, not in the table->expr_arena.

revert part of the 5acd391e. Instead, change the arena correctly
in fix_all_session_vcol_exprs().

Remove TABLE_ARENA, that was introduced in 5acd391e to force
item tree changes to be rolled back (because they were allocated in the
wrong arena and didn't persist. now they do)

* Item_default_value::fix_fields creates a copy of its argument's field.
* Field::default_value is changed when its expression is prepared in
  unpack_vcol_info_from_frm()

This means we must unpack any vcol expression that includes DEFAULT(x)
strictly after unpacking x->default_value.

To avoid building and solving this dependency graph on every table open,
we update Item_default_value::field->default_value after all vcols
are unpacked and fixed.

bt full - to include args and locals.

set print sevenbit on
  - it is more useful to be able to see the exact bytes
    (in case something is dumped as a string and not hexadecimal digits)
set print static-members off
  - there are many interesting (non-const) static members
set frame-arguments all
  - even non-printables are useful to see.

Let's make our bb logs give a little bit more detail on those
hard to reproduce bugs.

Tests on rhel7's gdb-7.6.1-120.el7

I change from `exit;` to `exit(1);` on a function `usage()`.
When we try to run mtr with a wrong option, a function `usage()` is called with the wrong option as its argument. In this case, because the function call `exit` in a first if statement, we get exit status 0.

This is a temporary fix for 10.2.
This problem was permanently fixed in 10.9 under terms of MDEV-27743.

This patch should propagate up to 10.8 then null-merged to 10.9.

Creating a temporary table with Spider is non-sense because a Spider
table cannot hold any physical data and it requires an additional
effort to manage even if it is configured correctly.

Set HTON_TEMPORARY_NOT_SUPPORTED to spider_hton->flags.  

Reviewed-by: nayuta.yanagisawa@hey.com
Co-authored-by: d8sk4ueun@gmail.com

The partitioning engine does not support the table-level DATA/INDEX
DIRECTORY specification.

If one create a non-partitioned table with the DATA/INDEX DIRECTORY
option and then performs ALTER TABLE ... PARTITION BY on it, the
DATA/INDEX DIRECTORY specification of the old schema is ignored.

The behavior might be a bit surprising for users because the value
of a usual table option applies to all the partitions. Thus, we raise
a warning on such ALTER TABLE ... PARTITION BY.

The cause of the bug is overflow of uint16 KEY_PART_INFO::length and/or
uint16 KEY_PART_INFO::store_length. The solution is to increase the size
of those variables to the 'uint' type (which is 32-bit long)