MDEV-16153 Server crashes in Apc_target::disable, ASAN heap-use-after-free in Explain_query::~Explain_query upon/after EXECUTE IMMEDIATE

Explain_query must be created in the execution arena.
But JOIN::optimize_inner temporarily switches to the statement arena
under `if (sel->first_cond_optimization)`. This might cause
Explain_query to be allocated in the statement arena. Usually it is
harmless (although technically incorrect and a waste of memory), but
in case of EXECUTE IMMEDIATE, Prepared_statement object and its
statement arena are destroyed before log_slow_statement() call,
which uses Explain_query.

Fix:
1. Create Explain_query before switching arenas.
2. Before filling earlier-created Explain_query with data, set
thd->mem_root from the Explain_query::mem_root

Itcan happen that the connection is already gone during the window
between quering I_S.PROCESSLIST and KILL QUERY.

Fix is to tolerate ER_NO_SUCH_THREAD returned from KILL QUERY.

Add small improvement in message "Killing MDL query " to actually output
the query.
Also do not try to kill queries that are already in Killed state.

fix a typo that broke the main.view test

followup for ef295c31

Apply patch by Oleksandr Byelkin:
Do not use "only index read" in analyzing indices if there is a field which present in the index only partially.

Mark the plugin as dynamic-only.

It should work ok on all Unixes, but on Windows ,only worked by accident
in the past, with client not being Unicode safe.

It stopped working with Visual Studio 2017 15.7 update now.

The crash occurs when a thread that is closing its connection attempts to
access Spider transaction information when another thread has freed that memory
while processing Spider plugin deinit.  This occurs because Spider does not
adjust the plugin's reference count when it sets a transaction information
pointer for the plugin.

The fix I implemented changes the way Spider sets the transaction information
pointer to use thd_set_ha_data() so that Spider's plugin reference counter is
adjusted as well.

Author:
  Jacob Mathew.

Reviewer:
  Kentoku Shiba.

Merged From:
  Commit ab9d420d on branch 10.2

Fix two issues:
1. Rdb_ddl_manager::rename() loses the value of m_hidden_pk_val. new
object used to get 0, which means "not loaded from the db yet".

2. ha_rocksdb::load_hidden_pk_value() uses current transaction (and its
snapshot) when loading hidden PK value from disk. This may cause it to
load an out-of-date value.

The current code does not support recursive CTEs whose specifications
contain a mix of ALL UNION and DISTINCT UNION operations.
This patch catches such specifications and reports errors for them.

           with recursive subquery

There were two problems:
1. The code did not report that usage of global ORDER BY / LIMIT clauses
was not supported yet.
2. The code just reset fake_select_lex of the the unit specifying
a recursive CTE to NULL and that caused memory leaks in some cases.

The crash occurs when a thread that is closing its connection attempts to
access Spider transaction information when another thread has freed that memory
while processing Spider plugin deinit.  This occurs because Spider does not
adjust the plugin's reference count when it sets a transaction information
pointer for the plugin.

The fix I implemented changes the way Spider sets the transaction information
pointer to use thd_set_ha_data() so that Spider's plugin reference counter is
adjusted as well.

Author:
  Jacob Mathew.

Reviewer:
  Kentoku Shiba.

Merged From:
  Commit eabfadce on branch bb-10.3-MDEV-7914

When Item_insert_value needs a dummy field,
use zero-length Field_string, not Field_null.
The latter isn't compatible with CREATE ... SELECT.

jemalloc > 5.0.0 doesn't like to be linked with
a dlopen-ed module.

Don't link tokudb with jemalloc on Fedora 28,
LD_PRELOAD it instead with mysqld_safe
and with systemd.

Fixed by extending unique_table() with a flag to not allow usage of
the replaced table.

I also cleaned up find_dup_table() to not use goto next.
I also added more comments to the code in find_dup_table()

Analyze core independently of max-save-datadir and max-save-core setting.

Increment $num_saved_cores only if core was actually saved.

"Move any core files from e.g. mysqltest" independently of
max-save-datadir setting. Note: it may overwrite core from mysqld, which
might not be desired (it did work this way even before).

srv_purge_coordinator_thread(): Wait for all purge worker threads
to actually exit. An analysis of a core dump of a hung 10.3 server
revealed that one srv_worker_thread did not exit, even though the
purge coordinator had exited. This caused kill_server_thread and
mysqld_main to wait indefinitely. The main InnoDB shutdown was
never called, because unireg_end() was never called.

- Added missing test case for MyISAM

Imported the following test case from mysql to MariaDB

1) innodb.alter_kill
2) innodb.alter_foreign_crash
3) innodb.alter_rename_files
4) innodb.analyze_table
5) Appended the case in innodb-online-alter-gis

Problem:
We keep pinning pages in dict_stats_analyze_index_below_cur(),
but doesn't release these pages. When we have a relative small
buffer pool size, and big innodb_stats_persistent_sample_pages,
there will be no free pages for use.

Solution:
Use a separate mtr in dict_stats_analyze_index_below_cur(),
and commit mtr before return.
Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
RB: 11362

In debug builds of MySQL, there is an configuration variable
that allows an InnoDB log checkpoint to be initiated:

SET GLOBAL innodb_log_checkpoint_now=ON;

Setting this variable while a table-rebuilding ALTER TABLE is executing
may result in an infinite loop.

checkpoint_now_set(): Account for log_sys->append_on_checkpoint->size().
Note that this function contains race conditions, because it is accessing
fields of log_sys without holding log_sys->mutex. We think that this is
acceptable, because this variable only exists for debugging purposes, in
debug builds of MySQL.

RB: 9947
Reviewed-by: Sunny Bains <sunny.bains@oracle.com>

to innodb.innodb-online-alter-gis

Problem:

The function row_build_index_entry_low() takes a dtuple_t object ('row') and
dict_index_t object ('index') as input and returns a new dtuple_t object
('entry') as output.  The dtuple_t object 'row' that is given as input might
have been constructed from a different dict_index_t object (!= index).  So
when accessing the externally stored data of the given 'row' we need to make
use of the correct index object.

Solution:

Store the page size information in the associated row_ext_t object.

rb#6086 approved by Vasil and Jimmy.

Problem:

Suppose there are two tables in the database related through a foreign key
constraint - the parent table and the child table.  Suppose there is an ALTER
TABLE on the child table which gets interrupted in such a way that the child
table is not available any more.

After crash recovery, an ALTER TABLE on the parent table identifies that its
foreign keys cannot be loaded.  This results in an error and a debug assert.

Solution:

Remove the debug assert and change error to a warning.

rb#8658 approved by Marko.

New added test case: alter_kill in innodb suite.

The server crashes on a SELECT because of space id mismatch. The
mismatch happens if the server crashes during an ALTER TABLE.

There are actually two cases of inconsistency, and three fixes needed
for the InnoDB problems.

We have dictionary data (tablespace or table name) in 3 places:

(a) The *.frm file is for the old table definition.
(b) The InnoDB data dictionary is for the new table definition.
(c) The file system did not rename the tablespace files yet.

In this fix, we will not care if the *.frm file is in sync with the
InnoDB data dictionary and file system. We will concentrate on the
mismatch between (b) and (c).

Two scenarios have been mentioned in this bug report. The simpler one
first:

1. The changes to SYS_TABLES were committed, and MLOG_FILE_RENAME2
records were written in a single mini-transaction commit.
The files were not yet renamed in the file system.
2a. The server is killed, without making a log checkpoint.
3a. The server refuses to start up, because replaying MLOG_FILE_RENAME2
fails.

I failed to repeat this myself. I repeated step 3a with a saved
dataset. The problem seems to be that MLOG_FILE_RENAME2 replay is
incorrectly being skipped when there is no page-redo log or
MLOG_FILE_NAME record for the old name of the tablespace.

FIX#1: Recover the id-to-name mapping also from MLOG_FILE_RENAME2
records when scanning the redo log. It is not necessary to write
MLOG_FILE_NAME records in addition to MLOG_FILE_RENAME2 records for
renaming tablespace files.

The scenario in the original Description involves a log checkpoint:
1. The changes to SYS_TABLES were committed, and MLOG_FILE_RENAME2
records were written in a single mini-transaction commit.
2. A log checkpoint and a server kill was injected.
3. Crash recovery will see no records (other than the MLOG_CHECKPOINT).
4. dict_check_tablespaces_and_store_max_id() will emit a message about
a non-found table #sql-ib22*.
5. A mismatch is triggering the assertion failure.

In my test, at step 4 the SYS_TABLES root page (0:8) contains these 3
records right before the page supremum:
* delete-marked (committed) name=#sql-ib21* record, with space=10.
* name=#sql-ib22*, space=9.
* name=t1, space=10.
space=10 is the rebuilt table (#sql-ib21*.ibd in the file system).
space=9 is the old table (t1.ibd in the file system).

The function dict_check_tablespaces_and_store_max_id() will enter
t1.ibd with space_id=10 into the fil_system cache without noticing
that t1.ibd contains space_id=9, because it invokes
fil_open_single_table_tablespace() with validate=false.

In MySQL 5.6, the space_id from all *.ibd files are being read when
the redo log checkpoint LSN disagrees with the FIL_PAGE_FILE_FLUSH_LSN
in the system tablespace. This field is only updated during a clean
shutdown, after performing the final log checkpoint.

FIX#2: dict_check_tablespaces_and_store_max_id() should pass
validate=true to fil_open_single_table_tablespace() when a non-clean
shutdown is detected, forcing the first page of each *.ibd file to be
read. (We do not want to slow down startup after a normal shutdown.)

With FIX#2, the SELECT would fail to find the table. This would
introduce a regression, because before WL#7142, a copy of the table
was accessible after recovery.

FIX#3: Maintain a list of MLOG_FILE_RENAME2 records that have been
written to the redo log, but not performed yet in the file system.
When performing a checkpoint, re-emit these records to the redo
log. In this way, a mismatch between (b) and (c) should be impossible.

fil_name_process(): Refactored from fil_name_parse(). Adds an item to
the id-to-filename mapping.

fil_name_parse(): Parses and applies a MLOG_FILE_NAME,
MLOG_FILE_DELETE or MLOG_FILE_RENAME2 record. This implements FIX#1.

fil_name_write_rename(): A wrapper function for writing
MLOG_FILE_RENAME2 records.

fil_op_replay_rename(): Apply MLOG_FILE_RENAME2 records. Replaces
fil_op_log_parse_or_replay(), whose logic was moved to fil_name_parse().

fil_tablespace_exists_in_mem(): Return fil_space_t* instead of bool.

dict_check_tablespaces_and_store_max_id(): Add the parameter
"validate" to implement FIX#2.

log_sys->append_on_checkpoint: Extra log records to append in case of
a checkpoint. Needed for FIX#3.

log_append_on_checkpoint(): New function, to update
log_sys->append_on_checkpoint.

mtr_write_log(): New function, to append mtr_buf_t to the redo log.

fil_names_clear(): Append the data from log_sys->append_on_checkpoint
if needed.

ha_innobase::commit_inplace_alter_table(): Add any MLOG_FILE_RENAME2
records to log_sys->append_on_checkpoint(), and remove them once the
files have been renamed in the file system.

mtr_buf_copy_t: A helper functor for copying a mini-transaction log.

rb#6282 approved by Jimmy Yang

In this issue we hit the assert because we are adding addition fields to the field JOIN::all_fields list. This
is done because  HEAP tables can't index BIT fields so  we need to use an additional hidden field for grouping because later it will be
converted to a LONG field. Original field will remain of the BIT type and will be returned. This happens when we convert DISTINCT to
GROUP BY.

The solution is to take into account the number of such hidden fields that would be added to the field
JOIN::all_fields list while calculating the size of the ref_pointer_array.

Problem was that verify_constraints() didn't check if
there was an error as part of evaluating constraints
(can happen in strict mode).

In one-row-insert the error was ignored when using
binary logging as binary logging clear errors if insert
succeeded. In multi-row-insert the error was noticed
for the second row.

After this fix one will get an error for both one and
multi-row inserts if the constraints generates a warning
in strict mode.

followup for 21bcfeb9

Problem was that if copy_data_between_tables() didn't do proper
clean up in case of failures:
- copy object was not properly freed
- end_bulk_insert() was not called
- mysql_trans_prepare_alter_copy_data() set THD->transaction.on to
  false which was not properly restored

The last part caused a crash in Aria as Aria depends on that THD
is correct.

Other things:
- Reset info->switched_transactional after usage (safety)
- Reset bulk_insert_single_undo (safety)