If InnoDB is killed while ALTER TABLE...ALGORITHM=COPY is in progress,
after recovery there could be undo log records some records that were
inserted into an intermediate copy of the table. Due to these undo log
records, InnoDB would resurrect locks at recovery, and the intermediate
table would be locked while we are trying to drop it. This would cause
a call to row_rename_table_for_mysql(), either from
row_mysql_drop_garbage_tables() or from the rollback of a RENAME
operation that was part of the ALTER TABLE.
row_rename_table_for_mysql(): Do not attempt to parse FOREIGN KEY
constraints when renaming from #sql-something to #sql-something-else,
because it does not make any sense.
row_drop_table_for_mysql(): When deferring DROP TABLE due to locks,
do not rename the table if its name already starts with the #sql-
prefix, which is what row_mysql_drop_garbage_tables() uses.
Previously, the too strict prefix #sql-ib was used, and some
tables were renamed unnecessarily.
This reverts commit 7069071d7d
And add a test to show that optimization steps that
a) are repeated for every execution
b) create new items
cannot be done on the statement arena
1. Moving the following methods from THD to Item_change_list:
nocheck_register_item_tree_change()
check_and_register_item_tree_change()
rollback_item_tree_changes()
as they work only with the "change_list" member and don't
require anything else from THD.
2. Deriving THD from Item_change_list
This change will help to fix "MDEV-14603 signal 11 with short stacktrace" easier.
Replace some !rw_lock_own() assertions with the stronger
!btr_search_own_any(). Remove some redundant btr_get_search_latch()
calls.
btr_search_update_hash_ref(): Remove a duplicated assertion.
btr_search_build_page_hash_index(): Remove a duplicated assertion.
rw_lock_s_lock() asserts that the latch is not being held.
btr_search_disable_ref_count(): Remove an assertion. The only caller
is acquiring all adaptive hash index latches.
innodb_init_param(): Initialize btr_ahi_parts=1 for Mariabackup.
btr_search_enabled: Let the adaptive hash index be disabled
in Mariabackup. This would potentially only matter during --export,
and --export performs a table scan, not many index lookups.
innobase_start_or_create_for_mysql(): Only start the data dictionary
and transaction subsystems in normal server startup and during
mariabackup --export.
btr_cur_update_in_place(): Read block->index only once,
so that it cannot change to NULL after the first read.
When block->index != NULL, it must be equal to index.
There was a lot of files generated by the sources that were not installed
in any package. This fixes most of those issues, but not all. Files still
outside any package are in the not-installed, which is used by dh_install.
Also make sure all configuration files are installed to the correct
location that matches layout used by Debian official packages.
Matching libmariadb-dev package contents in official Debian repositories,
the MariaDB Connector/C files should go into a folder using the 'mariadb'
name. For compatibility with sources that expect to find 'mysql' stuff,
create a symlink from include/mysql to include/mariadb.
Using this package any source that expects MySQL Client libraries should
build without changes. Sources that expect MariaDB Connector C should
build using only libmariadb-dev.
Current MariaDB Connector/C does not build quite identically in
this source tree compared to how it build in Debian official.
The remaining differences are tracked in MDEV-14921.
We already ship libmysqlclient18 that replaces any existing package
with the same name and install symlinks that point to out libmariadb.so.
Instead of creating more packages, we add just one more that does the
same and provides both libmysqlclient19 and -20 replacements symlinks.
This is a clean solution, because systems that only use (and are built
against) libmariadb will not need them and if somebody has done a mistake
in the linker parameters, they will spot it and can easily update the
filename to libmariadb.
- tokuft_logprint should be shipped in the TokuDB plugin
- mysql_install_db is needed for installing/upgrading the datadir
so it must be in the server core package so users can roll their
own upgrades
There is no point in having version suffixes in plugin packages. They
will via their control file anyway depend on the correct server or client
version. Having version suffices has no benefit and it just complicates
upgrades when a new major version name package needs to replace all
possible previous version.
This issue was overlooked when merging commit
844a575946 from 10.2 into 10.3, so it
needs to be manually fixed now.
The correct format for new Debian packages is to define install lists
as *.install files. This has already been fixed for 10.3, but it when
merging commit c5a525bda2 from 10.2, this
change was overlooked and a file of the old format slipped in.
The libmariadb-dev package must include this directory so that downstream
developers can intentionally include MariaDB libraries as they want.
This matches the contents of the official Debian libmariadb-dev package.
TokuDB and Mroonga are not built on Travis CI to save time. Previously
their packages were not created due to a hack in debian/rules, that got
removed in commit 9631d933fb. This change complements that commit.
btr_cur_update_in_place(): The call rw_lock_x_lock(ahi_latch) must
of course be inside the if (ahi_latch) condition. This is a mistake
that I made when backporting the fix-under-development from 10.3.
btr_cur_search_to_nth_level(), btr_search_guess_on_hash(),
btr_pcur_open_with_no_init_func(), row_sel_open_pcur():
Replace the parameter has_search_latch with the ahi_latch
(passed as NULL if the caller does not hold the latch).
btr_search_update_hash_node_on_insert(),
btr_search_update_hash_on_insert(),
btr_search_build_page_hash_index(): Add the parameter ahi_latch.
btr_search_x_lock(), btr_search_x_unlock(),
btr_search_s_lock(), btr_search_s_unlock(): Remove.
btr_cur_search_to_nth_level(), row_sel(): Do not bother to yield to
waiting exclusive lock requests on the adaptive hash index latch.
When the btr_search_latch was split into an array of latches
in MySQL 5.7.8 as part of the Oracle Bug#20985298 fix, the "caching"
of the latch across storage engine API calls was removed. Thus,
X-lock requests should have a good chance of becoming served, and
starvation should not be possible.
btr_search_guess_on_hash(): Clean up a debug assertion.
Also, use 32-bit native reads to read the 32-bit aligned
FIL_PAGE_PREV and FIL_PAGE_NEXT reads, to compare them to the
byte order agnostic pattern FIL_NULL (0xffffffff).
This is mere code clean-up; the reported problem was already fixed
in commit 3fdd390791.
row_sel(): Remove the variable search_latch_locked.
row_sel_try_search_shortcut(): Remove the parameter
search_latch_locked, which was always passed as nonzero.
row_sel_try_search_shortcut(), row_sel_try_search_shortcut_for_mysql():
Do not expect the caller to acquire the AHI latch. Instead,
acquire and release it inside this function.
row_search_mvcc(): Remove a bogus condition on mysql_n_tables_locked.
When the btr_search_latch was split into an array of latches
in MySQL 5.7.8 as part of the Oracle Bug#20985298 fix, the "caching"
of the latch across storage engine API calls was removed, and
thus it is unnecessary to avoid adaptive hash index searches
during INSERT...SELECT.
This is not fixing the reported problem, but a potential problem that was
introduced in MDEV-11369.
row_sel_try_search_shortcut(), row_sel_try_search_shortcut_for_mysql():
When an adaptive hash index search lands on top of rec_is_default_row(),
we must skip the candidate and perform a normal search. This is because
the adaptive hash index latch only protects the record from being deleted
but does not prevent concurrent inserts into the page. Therefore, it is not
safe to dereference the next-record pointer.
This race condition is a regression caused by MDEV-12121.
btr_cur_update_in_place(): Determine block->index!=NULL only once
in order to determine whether an adaptive hash index bucket needs
to be exclusively locked and unlocked.
If we evaluated block->index multiple times, and the adaptive hash
index was disabled before we locked the adaptive hash index, then
we would never release the adaptive hash index bucket latch, which
would eventually lead to InnoDB hanging.
