- If LooseScan is used with quick select, require that quick select produces
data in key order (this disables use of MRR, which can return data in arbitrary order).
The line in the file_contents.test removes all the '/lib' substrings from the
path, so file cannot be found if a path contains such a substring.
As i didn't find where it is needed, the line was just removed
per-file comments:
mysql-test/t/file_contents.test
mdev57 5.5 main.file_contents fails on debian5-i386-fulltest.
no '/lib' substring cutting.
not be reproduced in the latest release of mariadb-5.3 as it was was fixed
by Sergey Petrunia when working on the problems concerning outer joins within
in subqueries converted to semi-joins.
In 5.5, ssl_do() no longer calls report_errors() in case of ssl error.
Since report_errors() iterated over the list of errors, this means that we
now report the first error in the list, rather than the last. Adjust the
--replace_regex line for OpenSSL build accordingly in the test case.
Fixed Item* Item_equal::get_first(JOIN_TAB *context, Item *field_item) to work correctly in the case where:
- context!= NO_PARTICULAR_TAB, it points to a table within SJ-Materialization nest
- field_item points to an item_equal that has a constant Item_field but does not have any fields
from tables that are within semi-join nests.
I want to avoid that upgrades silently change important config parameters
that users have come to rely on. This could happen if users changed their
my.cnf themselves, and then an upgrade introduces mariadb.cnf which silently
overrides the settings in my.cnf. Avoid this by having mariadb.cnf mostly
empty for now, and in the future we can add just new mariadb-specific
options there that do not break existing installations.
mysql-common and places mariadb-specific stuff in /etc/mysql/conf.d/mariadb.cnf.
This should allow to co-exist with default Debian mysql-common package and
help resolve dependencies when installing mariadb among multiple available
versions of MySQL from different repositories.
- Disable use of join cache when we're using FirstMatch strategy, and the join
order is such that subquery's inner tables are interleaved with outer. Join
buffering code is incapable of handling such join orders.
- The testcase requires use of @@debug_optimizer_prefer_join_prefix to hit the bug,
but I'm pushing it anyway (including the mention of the variable in .test file),
so that it can be found and enabled when/if we get something comparable in the
main tree.
The problem was that LooseScan execution code assumed that tab->key holds
the index used for looseScan. This is only true when range or full index
scan are used. In case of ref access, the index is in tab->ref.key (and
tab->index==0 which explains how LooseScan passed tests with ref access: they
used one index)
Fixed by setting/using loosescan_key, which always the correct index#.
Don't log updates to performance schema in replication log.
Ensure that we don't call ha_update after ha_index_or_rnd_end() is called on slave.
.bzrignore:
Ignore some generated files
mysql-test/include/show_slave_status.inc:
Ensure that ./ is removed from file names
mysql-test/suite/perfschema/r/binlog_mix.result:
Updated results
mysql-test/suite/perfschema/r/binlog_row.result:
Updated results
mysql-test/suite/perfschema/r/binlog_stmt.result:
Updated results
mysql-test/suite/rpl/r/rpl_cant_read_event_incident.result:
Updated results
mysql-test/suite/rpl/r/rpl_performance_schema.result:
Ensure that we don't crash slave when we update performance schema
mysql-test/suite/rpl/t/rpl_performance_schema.test:
Ensure that we don't crash slave when we update performance schema
sql/log_event.cc:
Ensure that we don't call ha_update after ha_index_or_rnd_end() is called.
Remove old code that is not needed anymore (like restarting read loop over all rows if no matcing row is found)
Simplify code
sql/log_event_old.cc:
Ensure that we don't call ha_update after ha_index_or_rnd_end() is called.
storage/myisam/ha_myisam.cc:
More DBUG_PRINT
storage/perfschema/ha_perfschema.h:
Don't log updates to performance schema in replication log.
