In RHEL7/RHEL7.1 libcrack behavior seem to have been modified so that
"foobar" password is considered bad (due to descending "ba") earlier than
expected. For details google for cracklib-2.9.0-simplistic.patch.
Adjusted affected passwords not to have descending and ascending sequences.
The test created a file in location relative to the datadir
(a few levels above datadir).
The file was created by MariaDB server (via INTO OUTFILE), and
later removed by mysqltest (via remove_file). The problem is that
when the vardir is a symlink, MariaDB server and mysqltest can
resolve such paths differently. MariaDB server would return back
to where the symlink is located, while mysqltest would go above
the real directory. For example, if the test is run with --mem,
and /bld/5.5/mysql-test/var points at /dev/shm/var_auto_X, then
SELECT INTO OUTFILE created a file in /bld/5.5/mysql-test , but
remove_file would look for it in /dev/shm/.
The test is re-written so that all paths are resolved in perl,
the logic itself hasn't changed.
The reason for the assertion failure is that the update statement for
the minimal row image sets only the PK column in the write_set of the
table to true. On the other hand, the trigger aims to update a different
column.
Make sure that triggers update the used columns accordingly, when being
processed.
when replicating old temporal type fields (that don't store
metadata in the binlog), take the precision from
destination fields.
(this fixes the replication failure, crashes were
fixed in a different commit)
* Total order isolation was started twice for FLUSH TABLES, from
reload_acl_and_cache() and from mysql_execute_command(). Removed
the reload_acl_and_cache() part.
* Removed PXC specific stuff from MTR tests
- Eliminates code duplication in query cache patch
- Reduces the number of iterations in mysql-wsrep#201.test
to shorten the execution time
- Adds a new test case that exercises more scenarios
The admin commands in question are:
> OPTIMIZE
> REPAIR
> ANALYZE
For LOCAL or NO_WRITE_TO_BINLOG invocations of these commands, ie
OPTIMIZE LOCAL TABLE <t1>
they are not binlogged as expected.
Also, in addition, they are not executed under TOI.
Hence, they are not propagated to other nodes.
The effect is same as that of wsrep_on=0.
Also added tests for this.
A WSREP_DEBUG for wsrep_register_hton has also been added.
The galera_flush_local test has also been updated for verifying that effects
of NO_WRITE_TO_BINLOG / LOCAL are equivalent to wsrep_on=0 from wsrep
perspective.
(cherry picked from commit 5065122f94a8002d4da231528a46f8d9ddbffdc2)
Conflicts:
sql/sql_admin.cc
sql/sql_reload.cc
sql/wsrep_hton.cc
- Fixes query cache so that it is aware of wsrep_sync_wait.
Query cache would return (possibly stale) results to the
client, regardless of the value of wsrep_sync_wait.
- Includes the test case that reproduced the issue.
- Removes useless call to wsrep_xid_init() in wsrep_apply_events().
Transaction's xid is already initialized at that point.
- Adds call to wsrep_set_SE_checkpoint() for committing TOI events
in the applier side.
- Includes test case that reproduced the issue.
There was two problems. Firstly, if page in ibuf is encrypted but
decrypt failed we should not allow InnoDB to start because
this means that system tablespace is encrypted and not usable.
Secondly, if page decrypt is detected we should return false
from buf_page_decrypt_after_read.
