The assertion is there to catch cases where we rollback while
mark_start_commit() is active. This can allow following event groups
to be replicated too early, causing conflicts.
But in this case, we have an _explicit_ ROLLBACK event in the binlog,
which should not assert.
We fix this by delaying the mark_start_commit() in the explicit
ROLLBACK case. It seems safest to delay this in ROLLBACK case anyway,
and there should be no reason to try to optimise this corner case.
and vcol_supported_sql_funcs_innodb. Moving the test for using CHARSET(),
COLLATION(), COERCIBILITY() in virtual column from
vcol_supported_sql_funcs_xxx to vcol_blocked_sql_funcs_xxx,
as these functions are not supported in virtual columns any longer.
Discussed with Sanja on IRC.
- foreign_keys: adjusted according to code changes;
- type_spatial: adjusted according to code changes;
- type_spatial_indexes (for MyISAM): disabled till MDEV-8675 is fixed
In original code, sometimes one got an automatic DEFAULT value in some cases, in other cases not.
For example:
create table t1 (a int primary key) - No default
create table t2 (a int, primary key(a)) - DEFAULT 0
create table t1 SELECT .... - Default for all fields, even if they where defined as NOT NULL
ALTER TABLE ... MODIFY could sometimes add an unexpected DEFAULT value.
The patch is quite big because we had some many test cases that used
CREATE ... SELECT or CREATE ... (...PRIMARY KEY(xxx)) which doesn't have an automatic DEFAULT anymore.
Other things:
- Removed warnings from InnoDB when waiting from semaphore (got this when testing things with --big)
While sql_bin_log=1(0) is meant to control binary logging for the
current session so that the updates to do(not) get logged into the
binary log to be replicated to the async MariaDB slave. The same
should not affect galera replication.
That is, the updates should always get replicated to other galera
nodes regardless of sql_bin_log's value.
Fixed by making sure that the updates are written to binlog cache
irrespective of sql_bin_log.
Added test cases.
Analysis: Handler table flag HA_REQUIRE_PRIMARY_KEY alone is not enough
to force primary or unique key, if table has at least one NOT NULL
column and secondary key for that column.
Fix: Add additional check that table really has primary key or
unique key for InnoDB terms.
This bug is essentially another variant of MDEV-7458.
If a transaction conflict caused a deadlock kill of T2 in record_gtid()
during commit, the code would do a rollback _before_ running
rgi->unmark_start_commit(). This creates a race where following transactions
could start too early (before T2 has completed its transaction retry). This
in turn could lead to replication failure, if there was a conflict that
caused eg. duplicate key error or similar.
The fix is to remove these rollbacks (in Query_log_event::do_apply_event()
and Xid_log_event::do_apply_event(). They seem out-of-place; code in
log_event.cc generally does not roll back on error, this is handled higher
up.
In addition, because of the extreme difficulty of reproducing bugs like
MDEV-7458 and MDEV-8302, this patch adds some extra precations to try to
detect (in debug builds) or prevent (in release builds) similar bugs.
ha_rollback_trans() will now call unmark_start_commit() if needed (and
assert in debug build when a caller does rollback without unmark first).
We also add an extra check for thd->killed() so that we avoid doing
mark_start_commit() if we already have a pending deadlock kill.
And we add a missing unmark_start_commit() call in the error case, found by
the above assertion.
Analysis: There is race between drop table and encryption threads that
could cause encryption thread to enter mutex that has been already
released.
Fix: When destroying crypt_data first enter the mutex and set crypt data
unavailable, then release the memory and clean up the data. This should
make the race more unprobable. Additionally, added big_test for
create_or_replace as it could fail testcase timeout
if you have slow I/O (tested that testcase passes with --mem).
Test create_or_replace should make sure that background decrypt
operation is finished and flush all dirty pages using restart
to clean up the database before ending.
* support statically compiled file_key_management when possible
* rename encryption.encryption_create_or_replace -> encryption.create_or_replace
* delete unnecessary *.opt file (including
have_key_management_plugin.inc is enough)
* remove unnecessary LOWER() for strings that are compared
case insensitively anyway
Disable sys_vars.all_vars test. There's no need to write
boilerplate tests for every new system variable, our
INFORMATION_SCHEMA.SYSTEM_VARIABLES and sysvar_* tests
are now used to show all basic properties of all variables.
Change session only variable enforce_storage_engine to be
session variable and make sure that also global value
is used if session variable is not set.
The --gtid-ignore-duplicates option was not working correctly with row-based
replication. When a row event was completed, but before committing, there
was a small window where another multi-source SQL thread could wrongly try
to re-execute the same transaction, without properly ignoring the duplicate
GTID. This would lead to duplicate key error or out-of-order GTID error or
similar.
Thanks to Matt Neth for reporting this and giving an easy way to reproduce
the issue.
Introduce a new dummy INFORMATION_SCHEMA.CHANGED_PAGE_BITMAPS table to XtraDB
with reset_table callback to allow FLUSH NO_WRITE_TO_BINLOG CHANGED_PAGE_BITMAPS
to be called from innobackupex.
Moved Apc_target::destroy(), Apc_target::enable() and Apc_targe::disable()
definitions to my_apc.h so that they can be inlined.
Apc_targe::disable() now calls Apc_target::process_apc_requests() only if
there're APC requests. This saves one pthread_mutex_lock() call.
Overhead change:
Apc_target::disable 0.04% -> out of radar
Apc_target::enable 0.03% -> out of radar
Apc_target::process_apc_requests 0.02% -> out of radar
pthread_mutex_lock 0.43% -> 0.42%
pthread_mutex_unlock 0.26% -> 0.25%
Added new dynamic configuration variable innodb_buf_dump_status_frequency
to configure how often buffer pool dump status is printed in the logs.
A number between [0, 100] that tells how oftern buffer pool dump status
in percentages should be printed. E.g. 10 means that buffer pool dump
status is printed when every 10% of number of buffer pool pages are
dumped. Default is 0 (only start and end status is printed).
in ha_delete_table()
* only convert ENOENT and HA_ERR_NO_SUCH_TABLE to warnings
* only return real error codes (that is, not ENOENT and
not HA_ERR_NO_SUCH_TABLE)
* intercept HA_ERR_ROW_IS_REFERENCED to generate backward
compatible ER_ROW_IS_REFERENCED
in mysql_rm_table_no_locks()
* no special code to handle HA_ERR_ROW_IS_REFERENCED
* no special code to handle ENOENT and HA_ERR_NO_SUCH_TABLE
* return multi-table error ER_BAD_TABLE_ERROR <table list> only
when there were many errors, not when there were many
tables to drop (but only one table generated an error)
