"Conditional jump or move depends on uninitialised value in
my_scan_weight_utf8_general_ci, main.mysql_client_test fails in biuldbot
with valgrind"
- Fixed by ensuring that engine_name is set to empty string even in case
errors in the .frm file
- Added some error checking to ha_table_exists()
Optimizations:
* avoid faster ext_table_discovery_simple() *only* when there are
engines with discover_table_names() method *and* they look at
file names. P_S implements discover_table_names(), but it's not
a reason to use slower extension_based_table_discovery().
* don't pre-sort table names if ORDER BY or GROUP BY was specified
* starting from 10.3 only sort table names for SHOW commands
- Fix win64 pointer truncation warnings
(usually coming from misusing 0x%lx and long cast in DBUG)
- Also fix printf-format warnings
Make the above mentioned warnings fatal.
- fix pthread_join on Windows to set return value.
For running the Galera tests, the variable my_disable_leak_check
was set to true in order to avoid assertions due to memory leaks
at shutdown.
Some adjustments due to MDEV-13625 (merge InnoDB tests from MySQL 5.6)
were performed. The most notable behaviour changes from 10.0 and 10.1
are the following:
* innodb.innodb-table-online: adjustments for the DROP COLUMN
behaviour change (MDEV-11114, MDEV-13613)
* innodb.innodb-index-online-fk: the removal of a (1,NULL) record
from the result; originally removed in MySQL 5.7 in the
Oracle Bug #16244691 fix
377774689b
* innodb.create-index-debug: disabled due to MDEV-13680
(the MySQL Bug #77497 fix was not merged from 5.6 to 5.7.10)
* innodb.innodb-alter-autoinc: MariaDB 10.2 behaves like MySQL 5.6/5.7,
while MariaDB 10.0 and 10.1 assign different values when
auto_increment_increment or auto_increment_offset are used.
Also MySQL 5.6/5.7 exhibit different behaviour between
LGORITHM=INPLACE and ALGORITHM=COPY, so something needs to be tested
and fixed in both MariaDB 10.0 and 10.2.
* innodb.innodb-wl5980-alter: disabled because it would trigger an
InnoDB assertion failure (MDEV-13668 may need additional effort in 10.2)
Assertions failed due to incorrect handling of the --tc-heuristic-recover
option when InnoDB is in read-only mode either due to innodb_read_only=1
or innodb_force_recovery>3. InnoDB failed to refuse a XA COMMIT or
XA ROLLBACK operation, and there were errors in the error handling in
the upper layer.
This was fixed by making InnoDB XA operations respect the
high_level_read_only flag. The InnoDB part of the fix and
parts of the test main.tc_heuristic_recover were provided
by Marko Mäkelä.
LOCK_log mutex lock/unlock had to be added to fix MDEV-13438.
The measure is confirmed by mysql sources as well.
For testing of the conflicting option combination, mysql-test-run is
made to export a new $MYSQLD_LAST_CMD. It holds the very last value
generated by mtr.mysqld_start(). Even though the options have been
also always stored in $mysqld->{'started_opts'} there were no access
to them beyond the automatic server restart by mtr through the expect
file interface.
Effectively therefore $MYSQLD_LAST_CMD represents a more general
interface to $mysqld->{'started_opts'} which can be used in wider
scopes including server launch with incompatible options.
Notice another existing method to restart the server with incompatible
options relying on $MYSQLD_CMD is is aware of $mysqld->{'started_opts'}
(the actual options that the server is launched by mtr). In order to use
this method they would have to be provided manually.
NOTE: When merging to 10.2, the file search_pattern_in_file++.inc
should be replaced with the pre-existing search_pattern_in_file.inc.
This is basically a duplicate or a reincarnation of MDEV-117.
For some reason, the test innodb.mdev-117 started failing in 10.2.
It is uncertain when this test started failing. The test is
nondeterministic, because there is a race condition between the
concurrently executing DELETE IGNORE and DELETE statements.
When a deadlock is reported for DELETE IGNORE, the SQL layer would
call handler::print_error() but then proceed to the next row,
as if no error had happened (which is the purpose of DELETE IGNORE).
So, when it proceeded to handler::ha_rnd_next(), InnoDB would hit an
assertion failure, because the transaction no longer exists, and we
are not executing at the start of a statement.
handler::print_error(): If thd_mark_transaction_to_rollback(thd, true)
was called, clear the ME_JUST_WARNING and ME_JUST_INFO errflags, so
that a note or warning will be promoted to an error if the transaction
was aborted by a storage engine.
and
MDEV-13011 Server crashes in THD::handle_condition or Assertion `! is_set() || m_can_overwrite_status' fails upon attempt to connect with max_session_mem_used = 8192
errors when a connection is killed in the
* TABLE_SHARE::init_from_sql_statement_string()
* THD::init()
also, safety-wise, don't check max_mem_used on free() and when some error
was already issued.
The sole purpose of handlerton::release_temporary_latches and its wrapper
function was to release the InnoDB adaptive hash index latch
(btr_search_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. As part of that,
the function trx_search_latch_release_if_reserved() was changed to an
assertion and the function trx_reserve_search_latch_if_not_reserved()
was removed, and handlerton::release_temporary_latches() practically
became a no-op.
Note: MDEV-12121 replaced the function
trx_search_latch_release_if_reserved()
with the more appropriately named macro trx_assert_no_search_latch().
bunch of bugs when external_lock() fails on unlock:
* mi_lock_database() used mi_mark_crashed() under share->intern_lock,
but mi_mark_crashed() itself locks this mutex.
* handler::close() required table to be unlocked, but failed
external_lock didn't count as unlock
* mysql_unlock_tables() ignored all unlock errors, but they still set
the error status in stmt_da.
The value of wsrep_affected_rows were not reseted properly for
slave. Now we also wsrep_affected_rows in Xid_log_event::do_apply_event
also , apart from THD::cleanup_after_query().
Signed-off-by: Sachin Setiya <sachin.setiya@mariadb.com>
Option wsrep_max_ws_rows is intended to limit the maximum number of rows
in a writeset. To enforce this limit, we increment THD::wsrep_affected_rows
on every INSERT, UPDATE or DELETE. The problem is that we do so even on
insertion to internal temporary tables used for SELECTs and such.
THD::wsrep_affected_rows is now incremented only for rows that are actually
replicated.
Signed-off-by: Sachin Setiya <sachinsetia1001@gmail.com>
Also, implement MDEV-11027 a little differently from 5.5 and 10.0:
recv_apply_hashed_log_recs(): Change the return type back to void
(DB_SUCCESS was always returned).
Report progress also via systemd using sd_notifyf().
it was race condition prone. instead use either a pair of my_delete()
calls with already resolved paths, or a safe high-level function
my_handler_delete_with_symlink(), like MyISAM and Aria already do.
TOCTOU bug. The path is checked to be valid, symlinks are resolved.
Then the resolved path is opened. Between the check and the open,
there's a window when one can replace some path component with a
symlink, bypassing validity checks.
Fix: after we resolved all symlinks in the path, don't allow open()
to resolve symlinks, there should be none.
Compared to the old MyISAM/Aria code:
* fastpath. Opening of not-symlinked files is just one open(),
no fn_format() and lstat() anymore.
* opening of symlinked tables doesn't do fn_format() and lstat() either.
it also doesn't to realpath() (which was lstat-ing every path
component), instead if opens every path component with O_PATH.
* share->data_file_name stores realpath(path) not readlink(path). So,
SHOW CREATE TABLE needs to do lstat/readlink() now (see ::info()),
and certain error messages (cannot open file "XXX") show the real
file path with all symlinks resolved.
* rename to "keyread" (to avoid conflicts with tokudb),
* change from bool to uint and store the keyread index number there
* provide a bool accessor to check if keyread is enabled
mark_columns_used_by_index used to do
reset + mark_columns_used_by_index_no_reset + start keyread + set bitmaps
Now prepare_for_keyread does that, while mark_columns_used_by_index
does only reset + mark_columns_used_by_index_no_reset,
just as its name suggests.
