The magic_n only complicated object destruction and did not serve
any useful purpose.

dict_sys_t::create(): Renamed from dict_init().

dict_sys_t::close(): Renamed from dict_close().

dict_sys_t::add(): Sliced from dict_table_t::add_to_cache().

dict_sys_t::remove(): Renamed from dict_table_remove_from_cache().

dict_sys_t::prevent_eviction(): Renamed from
dict_table_move_from_lru_to_non_lru().

dict_sys_t::acquire(): Replaces dict_move_to_mru() and some more logic.

dict_sys_t::resize(): Renamed from dict_resize().

dict_sys_t::find(): Replaces dict_lru_find_table() and
dict_non_lru_find_table().

Problem:
========
gcc 8 -O2 seems to indicate a real error for this code:

direct_pos= table->file->ha_table_flags() & HA_PRIMARY_KEY_REQUIRED_FOR_POSITION;

the warning: /mariadb/10.4/sql/rpl_gtid.cc:980:7:
warning: 'direct_pos' may be used uninitialized in this function [-Wmaybe-uninitialized]

Analysis:
=========
'direct_pos' is a variable which holds 'table_flags'. If this flag is set it means
that a record within a table can be directly located by using its position. If
this flag is set to '0' means there is no direct access is available, hence
index scan must be initiated to locate the record.  This direct_pos is used to
locate a row within mysql.gtid_slave_pos table for deletion.

Prior to the initialization of 'direct_pos' following steps take place.

1. mysql.gtid_slave_pos table is opened and 'table_opened' flag is set to true.
2. State check for mysql.gtid_slave_pos table is initiated.

If there is a failure during step2 code will be redirected to the error handling
part. This error handling code will access uninitialized value of 'direct_pos'.
This results in above mentioned warning.

Another issue found during analysis is the error handling code uses '!direct_pos'
to identify if the index is initialized or not. This is incorrect.

The index initialization code is shown below.

  if (!direct_pos && (err= table->file->ha_index_init(0, 0)))
    {
      table->file->print_error(err, MYF(0));
      goto end;
    }

In case there is a failure during ha_index_init code will be redirected to end
part which tries to close the uninitialized index. It will result in an assert

10.4/sql/handler.h:3186: int handler::ha_index_end(): Assertion `inited==INDEX'
failed.

Fix:
===
Introduce a new variable named 'index_inited'. Set this variable upon successful
initialization of index initialization otherwise by default it is false. Use
this variable during error handling.

This patch fixes:

- MDEV-19284 INSTANT ALTER with ucs2-to-utf16 conversion produces bad data
- MDEV-19285 INSTANT ALTER from ascii_general_ci to latin1_general_ci produces corrupt data

These regressions were introduced in 10.4.3 by:
- MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes

Changes:

1. Cleanup: Adding a helper method
   Field_longstr::csinfo_change_allows_instant_alter(),
   to remove some duplicate code in field.cc.

2. Cleanup: removing Type_handler::Charsets_are_compatible() and static
   function charsets_are_compatible() and
   introducing new methods in the recently added class Charset instead:
   - encoding_allows_reinterpret_as()
   - encoding_and_order_allow_reinterpret_as()

3. Bug fix: Removing the code that allowed instant conversion for
   ascii-to->8bit and ucs2-to->utf16.
   This actually fixes MDEV-19284 and MDEV-19285.

4. Bug fix: Adding a helper method Charset::collation_specific_name().
   The old corresponding code in Type_handler::Charsets_are_compatible()
   was not safe against (badly named) user-defined collations whose
   character set name can be longer than collation name.

row_build_spatial_index_key(): Return early if the column is missing
in the table row tuple.

This is a regression that was introduced by
commit 0e5a4ac2.

Step #2: "[ORDER BY ...] LIMIT n" should not prevent EXISTS-to-IN
conversion, as long as
- the LIMIT clause doesn't have OFFSET
- the LIMIT is not "LIMIT 0".

Step 1: Removal of ORDER BY [LIMIT] from the subquery should be done
earlier and for broader class of subqueries.

The rewrite was done in Item_in_subselect::select_in_like_transformer(),
but this had problems:
- It didn't cover EXISTS subqueries
- It covered IN-subqueries, but was done after the semi-join transformation
  was considered inapplicable, because ORDER BY was present.

Remaining issue:
- EXISTS->IN transformation happens before
  check_and_do_in_subquery_rewrites() is called, so it is still prevented
  by the present ORDER BY.

Make sure that SIGNALs are not overwritten before they
are received.

Use different signal names, so that subsequent WAIT_FOR is not awaken by
previous signal.

MDEV-19277: Add status variable that gets incremented if connection is aborted prior to authentication
MDEV-19282: Log more specific warning with log_warnings=2 if connection is aborted prior to authentication

In 62d28f83 the CMake variable
IS_BIG_ENDIAN became orphaned. Remove it.

In wsrep_plugins_post_init we iterate all theads and if they are
galera appliers (wsrep_applier) we init session variables. However,
current_thd was not set and recent changes on session variables
require holding LOCK_gloal_system_variables mutex.

This is 10.4 version.

With MDEV-19384 fixed FTWRL releases HANDLER locks early, which allows
concurrent threads to go. Test case may get stuck on FTWRL waiting for
LOCK TABLES.

- Remove warning about aria_control_file
- Write to unique test file

Other things:
- Fixed typo in aria_chk --help

So to push index condition for each join tab we have calculate the index condition that can be pushed and then
remove this index condition from the original condition. This is done through the function make_cond_remainder.
The problem is the function make_cond_remainder does not remove index condition when there is an OR operator.

Fixed this by making the function make_cond_remainder to keep in mind of the OR operator.
Also updated results for multiple test files which were incorrectly updated by the commit e0c1b3f2

code which was supposed to remove the condition present in the index
condition was not getting executed when the condition had OR operator, with AND the pushed
index condition was getting removed from where.

This problem affects all versions starting from 5.5 but this is a performance improvement, so fixing it in 10.4

Problem was that SHOW CREATE didn't remove PAGE_CHECKSUM=1

Signed-off-by: hygonsoc <hygonsoc@gmail.com>

For a table column `a`, the above expressions logically
equate to false in all cases.

With this patch the optimizer knows about this and queries
like:

SELECT * FROM t1 WHERE a!=a

no longer need to evaluate a!=a for every row.

The same applies if the expression was `a<a`, or `a>a`

An `EXPLAIN SELECT COOUNT(*) FROM t1 WHERE a<a` will show:

id     select_type     table   type    possible_keys   key     key_len ref     rows    Extra
1      SIMPLE  NULL    NULL    NULL    NULL    NULL    NULL    NULL    Impossible WHERE

Similarly `NOT (a!=a)` is always true.

EXPLAIN SELECT COUNT(*) FROM t1 WHERE not (a!=a);
id     select_type     table   type    possible_keys   key     key_len ref     rows    Extra
1      SIMPLE  NULL    NULL    NULL    NULL    NULL    NULL    NULL    Select tables optimized away

With MAX_INDEXIES=64(default), key_map=Bitmap<64> is just a wrapper around
ulonglong and thus "trivial" (can be bzero-ed, or memcpy-ed, and stays
valid still)

With MAX_INDEXES=128, key_map = Bitmap<128> is not a "trivial" type
anymore. The implementation uses MY_BITMAP, and MY_BITMAP contains pointers
which make Bitmap invalid, when it is memcpy-ed/bzero-ed.

The problem in 10.4 is that there are many new key_map members, inside TABLE
or KEY, and those are often memcopied and bzeroed

The fix makes Bitmap "trivial", by inlining most of MY_BITMAP functionality.
pointers/heap allocations are not used anymore.

Parenthesis around table names and derived tables should be allowed
in FROM clauses and some other context as it was in earlier versions.

Returned test queries that used such parenthesis in 10.3 to their
original form. Adjusted test results accordingly.

The deadlock happened between FTWRL under open HANDLER, LOCK TABLE and
DROP DATABASE

Fixed by reverting the previous fix for handler open in
lock_global_read_lock()

Fixed the original (wrong) test case in flush_read_lock.test to be
repeatable.

Windows does atomic writes, as long as they are aligned and multiple
of sector size. this is documented in MSDN.

Fix innodb.doublewrite test to always use doublewrite buffer,
(even if atomic writes are autodetected)

Fallback to detecting if TRIM is enabled, if we cannot determine
seek penalty.

If handler->inited is RND use cloned handler for long unique duplicate search.

Regression after reverting fair THD members constructors/destructors.
vars_list can be used standalone, in such cases destructor is needed.

Part of MDEV-14984 - regression in connect performance

The accessor dtuple_get_nth_v_field() was defined differently between
debug and release builds in MySQL 5.7.8 in
mysql/mysql-server@c47e1751b742454de553937039bbf2bcbe3c6bc7
and a debug assertion to document or enforce the questionable assumption
tuple->v_fields == &tuple->fields[tuple->n_fields] was missing.

This was apparently no problem until MDEV-11369 introduced instant
ADD COLUMN to MariaDB Server 10.3. With that work present, in one
test case, trx_undo_report_insert_virtual() could in release builds
fetch the wrong value for a virtual column.

We replace many of the dtuple_t accessors with const-preserving
inline functions, and fix missing or misleadingly applied const
qualifiers accordingly.

log_checkpoint(), log_make_checkpoint_at(): Remove the parameter
write_always. It seems that the primary purpose of this parameter
was to ensure in the function recv_reset_logs() that both checkpoint
header pages will be overwritten, when the function is called from
the never-enabled function recv_recovery_from_archive_start().

create_log_files(): Merge recv_reset_logs() to its only caller.

Debug instrumentation: Prefer to flush the redo log, instead of
triggering a redo log checkpoint.

page_header_set_field(): Disable a debug assertion that will
always fail due to MDEV-19344, now that we no longer initiate
a redo log checkpoint before an injected crash.

In recv_reset_logs() there used to be two calls to
log_make_checkpoint_at(). The apparent purpose of this was
to ensure that both InnoDB redo log checkpoint header pages
will be initialized or overwritten.
The second call was removed (without any explanation) in MySQL 5.6.3:
mysql/mysql-server@4ca37968da54ddc6b3b6628f41428ddba1c79bb8

In MySQL 5.6.8 WL#6494, starting with
mysql/mysql-server@00a0ba8ad92569fcf08212b3b8cf046dc8a0ce10
the function recv_reset_logs() was not only invoked during
InnoDB data file initialization, but also during a regular
startup when the redo log is being resized.

mysql/mysql-server@45e91679832219e2593c77185342f11f85232b58
in MySQL 5.7.2 removed the UNIV_LOG_ARCHIVE code, but still
did not remove the parameter write_always.