MDEV-32737 innodb.log_file_name fails on Assertion `after_apply || !(blocks).end in recv_sys_t::clear

recv_group_scan_log_recs(): Set the debug flag recv_sys.after_apply
after actually completing the log scan.

In the test, suppress some errors that may be reported when
the crash recovery of RENAME TABLE t1 TO t2 is preceded by
copying t2.ibd to t1.ibd.

The test case can get extra rows in its output from table
performance_schema.table_handles, left there by an earlier test case (for
example main.long_unique_delayed). So force a server restart at the
beginning of the test.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

Partial revert of this commit:

  commit 6b685ea7
  Author: Sergei Golubchik <serg@mariadb.org>
  Date:   Wed Sep 28 18:55:15 2022 +0200

Don't hold LOCK_thd_data over run_commit_ordered(). Holding the mutex
is unnecessary and will deadlock if any code in a commit_ordered
handlerton call tries to take the mutex to change THD local data.

Instead, set the current_thd for the duration of the call to keep
asserts happy around LOCK_thd_data.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

- Rename files as requested by Vicentiu:
```
 mysql_json_mysql_upgrade.test                    -> mysql_upgrade_mysql_json.test
 mysql_json_mysql_upgrade_with_plugin_loaded.test -> mysql_upgrade_mysql_json_with_plugin_loaded.test
 mysql_json_mysql_upgrade_system_tables.test      -> mysql_upgrade_mysql_json_system_tables.test
```
- Related to PR #2790
- Reviewer: <daniel@mariadb.org>, <vicentiu@mariadb.org>

- Prevent opening of any user tables in case `upgrade-system-table`
option is used.
- Still there may be uninstalled data types in `mysql` system table so
allow it to perform.
- Closes PR #2790
- Reviewer: <daniel@mariadb.org>, <vicentiu@mariadb.org>

- Regression introduced in 957cb7b7
- Patch 4abb8216 change `mysql.user` to `mysql.global_priv` for
`add_anonymous.inc`, update `delete_anonymous.inc`.
- Added test case with `--skip-name-resolve`
- Add test case with anonymous user
  - Disable this test for windows, assignes current user to anonymous
  user.

Reviewed by: <serg@mariadb.com>

buf_page_free(): Flag the freed page as modified if it is found in
the buffer pool.

buf_flush_page(): If the page has been freed, ensure that the log
for it has been durably written, before removing the page
from buf_pool.flush_list.

FindBlockX: Find also MTR_MEMO_PAGE_X_MODIFY in order to avoid an
occasional failure of innodb.innodb_defrag_concurrent, which involves
freeing and reallocating pages in the same mini-transaction.

This fixes a regression that was introduced in
commit a35b4ae8 (MDEV-15528).

This logic was tested by commenting out the $shutdown_timeout line
from a test and running the following:

./mtr --rr innodb.scrub
rr replay var/log/mysqld.1.rr/mariadbd-0

A breakpoint in the modified buf_flush_page() was hit, and the
FIL_PAGE_LSN of that page had been last modified during the
mtr_t::commit() of a mini-transaction where buf_page_free()
had been executed on that page.

srv_all_undo_tablespaces_open(): While opening the extra unused
undo tablespaces, InnoDB should use ULINT_UNDEFINED instead of
SRV_SPACE_ID_UPPER_BOUND.

recv_recovery_from_checkpoint_start(): InnoDB should add the
redo log block header + trailer size while checking the	log
sequence number in log file with log sequence number in the
system tablespace first page.

In commit 384eb570 the debug check
was relaxed in trx_undo_header_create(), not in the intended function
trx_undo_write_xid().

fil_aio_callback(): Invoke fil_node_t::complete_write() before
releasing any page latch, so that in case a log checkpoint is
executed roughly concurrently with the first write into a file
since the previous checkpoint, we will not miss a fdatasync()
or fsync() call to make the write durable.

Problem:
========
- InnoDB fails to open undo tablespace when page0 is corrupted
and fails to throw error.

Solution:
=========
- InnoDB throws DB_CORRUPTION error when InnoDB encounters
page0 corruption of undo tablespace.

- InnoDB restores the page0 of undo tablespace from
doublewrite buffer if it encounters page corruption

- Moved Datafile::restore_from_doublewrite() to
recv_dblwr_t::restore_first_page(). So that undo
tablespace and system tablespace can use this function
instead of duplicating the code

srv_undo_tablespace_open(): Returns 0 if file doesn't exist
or ULINT_UNDEFINED if page0 is corrupted.

This reverts commit 03c9a4ef.

The fix is wrong. It was doing this: if the uninitialized
wait->m_class has some specific value, then don't initialize it.

Review cleanups.

There are many filesystem related errors that can occur with
MariaBackup. These already outputed to stderr with a good description of
the error. Many of these are permission or resource (file descriptor)
limits where the assertion and resulting core crash doesn't offer
developers anything more than the log message. To the user, assertions
and core crashes come across as poor error handling.

As such we return an error and handle this all the way up the stack.

This fixes up a merge of commit 4fb8f7d0
with respect to commit ea37b144.

Part of the test did not work with view_protocol as the query written
to the slow_log table is changed because of view_protocol.

There where several reasons why the test failed:
- Constructors for Field_double and Field_float changed an argument
  to the constructor instead of a the correct class variable.
- gcc 7.5.0 produced wrong code when inlining Field_double constructor
  into Field_test_double constructor.

Fixed by changing the correct class variable and make the constructors
not inline to go around the gcc bug.

The bug was in the test case.
The problem was that maria_empty_logs.inc deleted aria log files before
the server was properly shutdown.
Fixed by waiting for pid file to disappear before starting to delete log
files.

Other things:
- Fixed that translog_purge_at_flush() will not stop deleting files even
  if one file could not be deleted.

The problem was that sometimes InnoDB returned sligtly wrong record count
for table, which causes the optimizer to disregard the result from
the range optimizer. The end result was that the optimizer choosed a
ref access instead of a range access which caused errors in buildbot.

Fixed by adding more rows to the table to ensure that table scan is
more costly than range scan of the given interval.

log_t::create(): Return whether the initialisation succeeded.
It may fail if too large an innodb_log_buffer_size is specified.

copy_back(): Also copy the dummy empty ib_logfile0 so that
MariaDB Server 10.8 or later can be started after
--copy-back or --move-back.

Thanks to Daniel Black for reporting this.

This is a 10.5 version of
commit ebf36492

Spider is part of the server, and there's no need to check the
version.

All spider plugins are uninstalled in clean_up_spider.inc

DROP SERVER IF EXISTS makes things easier

Memory for type holders of the columns of a table value constructor must
be allocated only once.

Approved by Oleksandr Byelkin <sanja@mariadb.com>

is_file_on_ssd() is more expensive than it should be.
It caches the results by volume name, but still calls GetVolumePathName()
every time, which, as procmon shows, opens multiple directories in
filesystem hierarchy (db directory, datadir, and all ancestors)

The fix is to cache SSD status by volume serial ID, which is cheap to
retrieve with GetFileInformationByHandleEx()

The counter is global so we do not need add backup to it
if we do not zero it after taking the backup.

Fix row counters to be able to get any possible value.

trx_t::set_skip_lock_inheritance() must be invoked at the very beginning
of lock_release_on_prepare(). Currently  trx_t::set_skip_lock_inheritance()
is invoked at the end of lock_release_on_prepare() when lock_sys and trx
are released, and there can be a case when locks on prepare are released,
but "not inherit gap locks" bit has not yet been set, and page split
inherits lock to supremum.

Also reset supremum bit and rebuild waiting queue when XA is prepared.

Reviewed by: Marko Mäkelä

MDEV-29731 Assertion failure when HAVING in a correlated subquery references columns in the outer query

When resolving a column from the HAVING clause, a new Item_field
object may be created inside Item_ref::fix_fields().
But the object is created with an empty name resolution context,
which then leads to debug assertion failure during
Item_field::fix_fields().

The solution is to pass the correct name resolution context
when creating the Item_field object.

Reviewer: Oleksandr Byelkin (sanja@mariadb.com)

The table structure from MySQL-5.1.14 is:

CREATE TABLE `slow_log` (
  `start_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `user_host` mediumtext NOT NULL,
  `query_time` time NOT NULL,
  `lock_time` time NOT NULL,
  `rows_sent` int(11) NOT NULL,
  `rows_examined` int(11) NOT NULL,
  `db` varchar(512) DEFAULT NULL,
  `last_insert_id` int(11) DEFAULT NULL,
  `insert_id` int(11) DEFAULT NULL,
  `server_id` int(11) DEFAULT NULL,
  `sql_text` mediumtext NOT NULL
) ENGINE=CSV DEFAULT CHARSET=utf8 COMMENT='Slow log'

Even as far back as MySQL-5.5.40 this table could be created as NULLs
where not permitted in the CSV table time, but it seems they
where allowed sometime.

As the first part of mariadb-upgrade adds the column thread_id without
correcting the 'NULL'able status of existing columns it fails.

We reorder the sql statements in the ugprade as follows:

ALTER TABLE slow_log MODIFY {columns} {new types} NOT NULL,....

As thread_id doesn't exist in the above statement it was removed from
the first ALTER TABLE statement to prevent failure.

Previous ALTER TABLE slow_log where moved later appending thread_id
and rows_affected, and also enforces the type of thread_id if it
was incorrectly like the now first ALTER STATEMENT slow_log used
to do.