The previous fix (commit dcdc1c6d09)
should have removed the assertion from log_close(), because every
caller that requires this assertion is already asserting that log
writes are allowed. When fil_names_clear() is called, it must be
able to write the MLOG_CHECKPOINT records. The purpose of the debug
variable recv_no_log_write is to prevent the creation of page-level
redo log records, or modifications to persistent data.
Add suppressions for the read and decompression errors.
This may be 10.3 specific and related to MDEV-13536 which increases
purge activity. But it does not hurt to suppress rarely occurring
and plausible error messages for this fault-injection test already in 10.2.
backup_release(): New function, refactored from backup_finish().
Release some resources that may have been acquired by backup_startup()
and should be released even after a failed operation.
xtrabackup_backup_low(): Refactored from xtrabackup_backup_func().
xtrabackup_backup_func(): Always call backup_release() after calling
backup_start().
The test mariabackup.incremental_backup revealed a memory leak
in have_queries_to_wait_for(). The problem is that
xb_mysql_query() is being invoked with bool use_result=true
but the result is not being freed by mysql_store_result().
There are similar leaks in other functions.
have_queries_to_wait_for(): Invoke mysql_free_result() to
clean up after the mysql_store_result() that was invoked
by xb_mysql_query().
select_incremental_lsn_from_history(): Plug the leak on failure.
kill_long_queries(): Plug the memory leak.
(This function always leaked memory when it was called.)
The fix broke mariabackup --prepare --incremental.
The restore of an incremental backup starts up (parts of) InnoDB twice.
First, all data files are discovered for applying .delta files. Then,
after the .delta files have been applied, InnoDB will be restarted
more completely, so that the redo log records will be applied via the
buffer pool.
During the first startup, the buffer pool is not initialized, and thus
trx_rseg_get_n_undo_tablespaces() must not be invoked. The apply of
the .delta files will currently assume that the --innodb-undo-tablespaces
option correctly specifies the number of undo tablespace files, just
like --backup does.
The second InnoDB startup of --prepare for applying the redo log will
properly invoke trx_rseg_get_n_undo_tablespaces().
enum srv_operation_mode: Add SRV_OPERATION_RESTORE_DELTA for
distinguishing the apply of .delta files from SRV_OPERATION_RESTORE.
srv_undo_tablespaces_init(): In mariabackup --prepare --incremental,
in the initial SRV_OPERATION_RESTORE_DELTA phase, do not invoke
trx_rseg_get_n_undo_tablespaces() because the buffer pool or the
redo logs are not available. Instead, blindly rely on the parameter
--innodb-undo-tablespaces.
fails with ERROR_INVALID_FUNCTION
This DeviceIoControl seems to happen on different boxes from time to time,
and there is not much user can do about it.
Instead of error, log a single INFO message, so it does not disturb users
much.
Apply this patch from upstream:
commit 2c8deddfb67f1cd41ea3d1ac95aa1aa9327e3406
Author: Yoshinori Matsunobu <yoshinorim@users.noreply.github.com>
Date: Tue Aug 15 16:21:58 2017 -0700
Set exclusive_manual_compaction = false on manual compactions
Summary:
Combining exclusive manual compaction and
non-exclusive manual compaction may hit rocksdb assertion errors.
This diff makes all MyRocks internal manual compactions non exclusive.
Closes https://github.com/facebook/mysql-5.6/pull/682
Differential Revision: D5633619
Pulled By: yoshinorim
fbshipit-source-id: a90786d
The bug was caused by a defect of the patch for the bug 11081.
The patch was actually a port of the fix this bug from the mysql
code line. Later a correction of this fix was added to the
mysql code. Here's the comment this correction was provided with:
Bug#16499751: Opening cursor on SELECT in stored procedure causes segfault
This is a regression from the fix of bug#14740889.
The fix started using another set of expressions as the source for
the temporary table used for the materialized cursor. However,
JOIN::make_tmp_tables_info() calls setup_copy_fields() which creates
an Item_copy wrapper object on top of the function being selected.
The Item_copy objects were not properly handled by create_tmp_table -
they were simply ignored. This patch creates temporary table fields
based on the underlying item of the Item_copy objects.
The test case for the bug 13346 was taken from mdev-13380.
The test mis-used MTR's "restart the server if it crashed or exited"
feature to try starting MyRocks plugin with invalid arguments.
Changed the test to use the --default-storage-engine=myisam which
allows the server to start when MyRocks fails to start.
This removes the need to "start the server with the arguments which
will caused it to fail to start", and so removes the race conditions
with MTR server restart code and mysqld.*.expect file.
row_ins_check_foreign_constraint(): On timeout,
return DB_LOCK_WAIT_TIMEOUT instead of DB_LOCK_WAIT,
so that the lock wait will be properly terminated.
Also, replace some redundant assignments.
It looks like this bug was introduced in MySQL 5.7.8 by:
commit a97f6b91227c7e0fc3151cfe5421891e79c12d19
Author: Annamalai Gurusami <annamalai.gurusami@oracle.com>
Date: Tue Jun 9 16:02:31 2015 +0530
Bug #20953265 INNODB: FAILING ASSERTION: RESULT != FTS_INVALID
MDEV-13498 is a performance regression that was introduced in MariaDB 10.2.2
by commit fec844aca8
which introduced some Galera-specific conditions that were being
evaluated even if the write-set replication was not enabled.
MDEV-13246 Stale rows despite ON DELETE CASCADE constraint
is a correctness regression that was introduced by the same commit.
Especially the subcondition
!(parent && que_node_get_type(parent) == QUE_NODE_UPDATE)
which is equivalent to
!parent || que_node_get_type(parent) != QUE_NODE_UPDATE
makes little sense. If parent==NULL, the evaluation would proceed to the
std::find() expression, which would dereference parent. Because no SIGSEGV
was observed related to this, we can conclude that parent!=NULL always
holds. But then, the condition would be equivalent to
que_node_get_type(parent) != QUE_NODE_UPDATE
which would not make sense either, because the std::find() expression
is actually assuming the opposite when casting parent to upd_node_t*.
It looks like this condition never worked properly, or that
it was never properly tested, or both.
wsrep_must_process_fk(): Helper function to check if FOREIGN KEY
constraints need to be processed. Only evaluate the costly std::find()
expression when write-set replication is enabled.
Also, rely on operator<<(std::ostream&, const id_name_t&) and
operator<<(std::ostream&, const table_name_t&) for pretty-printing
index and table names.
row_upd_sec_index_entry(): Add !wsrep_thd_is_BF() to the condition.
This is applying part of "Galera MW-369 FK fixes"
f37b79c6da
that is described by the following part of the commit comment:
additionally: skipping wsrep_row_upd_check_foreign_constraint if thd has
BF, essentially is applier or replaying
This FK check would be needed only for populating parent row FK keys
in write set, so no use for appliers
trx_set_rw_mode(): Check the flag high_level_read_only instead
of testing srv_force_recovery (innodb_force_recovery) directly.
There is no need to prevent the creation of read-write transactions
if innodb_force_recovery=3 is used. Yes, in that mode any recovered
incomplete transactions will not be rolled back, but these transactions
will continue to hold locks on the records that they have modified.
If the new read-write transactions hit conflicts with already existing
(possibly recovered) transactions, the lock wait timeout mechanism
will work just fine.
collateral changes:
* remove a test from innodb_virtual_basic that is already present in
gcol_keys_innodb
* set thd->abort_on_warning for inplace alter, just like it's set
for copy_data_between_tables - to have warnings converted into
errors identically in all alter algorithms
* don't ignore errors in TABLE::update_virtual_field
doing SYSVAR_AUTOSIZE() because of back_log > max_connections
enabled "autosized" flag, and that made IS_SYSVAR_AUTOSIZE()
true, which triggered the second SYSVAR_AUTOSIZE.
Remove back_log <= max_connections limit, back_log
doesn't *always* have to be smaller than max_connections.
SQL Standard behavior for DROP COLUMN xxx RESTRICT:
* If a constraint (UNIQUE or CHECK) uses only the dropped column,
it's automatically dropped too. If it uses many columns - an error.
CMakeLists.txt - merge mistake, apparently
include/CMakeLists.txt - install from CMAKE_CURRENT_BINARY_DIR.
Only install from CMAKE_CURRENT_SOURCE_DIR, if it's different
from CMAKE_CURRENT_BINARY_DIR
mysql-test/CMakeLists.txt - INSTALL_MYSQL_TEST() macro installs
everything, no need to install mtr separately once again
mysql-test/lib/My/SafeProcess/CMakeLists.txt
MYSQL_ADD_EXECUTABLE includes INSTALL
sql-bench/CMakeLists.txt
list files explicitly. don't install garbage, don't process 'foo'
and 'foo.sh' separately, it's only one file to install, not two.
