The patch differs from the original MySQL patch as follows:
- All test case differences have been reviewed one by one, and
care has been taken to restore the original plan so that each
test case executes the code path it was designed for.
- A bug was found and fixed in MariaDB 5.3 in
Item_allany_subselect::cleanup().
- ORDER BY is not removed because we are unsure of all effects,
and it would prevent enabling ORDER BY ... LIMIT subqueries.
- ref_pointer_array.m_size is not adjusted because we don't do
array bounds checking, and because it looks risky.
Original comment by Jorgen Loland:
-------------------------------------------------------------
WL#5953 - Optimize away useless subquery clauses
For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are
meaningless:
* ORDER BY (since we don't support LIMIT in these subqueries)
* DISTINCT
* GROUP BY if there is no HAVING clause and no aggregate
functions
This WL detects and optimizes away these useless parts of the
query during JOIN::prepare()
HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
Attempt to update an InnoDB temporary table under LOCK TABLES
led to assertion failure in both debug and production builds
if this temporary table was explicitly locked for READ. The
same scenario works fine for MyISAM temporary tables.
The assertion failure was caused by discrepancy between lock
that was requested on the rows of temporary table at LOCK TABLES
time and by update operation. Since SQL-layer requested a
read-lock at LOCK TABLES time InnoDB engine assumed that upcoming
statements which are going to be executed under LOCK TABLES will
only read table and therefore should acquire only S-lock.
An update operation broken this assumption by requesting X-lock.
Possible approaches to fixing this problem are:
1) Skip locking of temporary tables as locking doesn't make any
sense for connection-local objects.
2) Prohibit changing of temporary table locked by LOCK TABLES ...
READ.
Unfortunately both of these approaches have drawbacks which make
them unviable for stable versions of server.
So this patch takes another approach and changes code in such way
that LOCK TABLES for a temporary table will always request write
lock. In 5.1 version of this patch switch from read lock to write
lock is done inside of InnoDBs handler methods as doing it on
SQL-layer causes compatibility troubles with FLUSH TABLES WITH
READ LOCK.
mysql-test/suite/innodb/r/innodb_mysql.result:
Added test for bug #11762012 - "54553: INNODB ASSERTS IN
HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
mysql-test/suite/innodb/t/innodb_mysql.test:
Added test for bug #11762012 - "54553: INNODB ASSERTS IN
HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
mysql-test/suite/innodb_plugin/r/innodb_mysql.result:
Added test for bug #11762012 - "54553: INNODB ASSERTS IN
HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
mysql-test/suite/innodb_plugin/t/innodb_mysql.test:
Added test for bug #11762012 - "54553: INNODB ASSERTS IN
HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
storage/innobase/handler/ha_innodb.cc:
Assume that a temporary table locked by LOCK TABLES can be updated
even if it was only locked for read and therefore an X-lock should
be always requested for such tables.
storage/innodb_plugin/handler/ha_innodb.cc:
Assume that a temporary table locked by LOCK TABLES can be updated
even if it was only locked for read and therefore an X-lock should
be always requested for such tables.
Adjusted the result files in the pbxt, innodb and innodb_plugin suites.
Commented out a failing test case in innodb.innodb_multi_update.test.
It should be returned back when the problem with multi-update of derived
tables (bug 784297) is resolved.
- Fixed some issues with partitions and connection_string, which also fixed lp:716890 "Pre- and post-recovery crash in Aria"
- Fixed wrong assert in Aria
Now need to merge with latest xtradb before pushing
sql/ha_partition.cc:
Ensure that m_ordered_rec_buffer is not freed before close.
sql/mysqld.cc:
Changed to use opt_stack_trace instead of opt_pstack.
Removed references to pstack
sql/partition_element.h:
Ensure that connect_string is initialized
storage/maria/ma_key_recover.c:
Fixed wrong assert
Problem is that these tests run with --innodb-lock-wait-timeout=2 in .opt
(and this is necessary as built-in innodb does not allow to change this
dynamically). This cases another part of the test to occasionally time
out an UPDATE, which subsequently caused the test case to timeout due to
waiting for a condition (successful UPDATE) that never occurs.
Fixed by re-trying the update in case of timeout.
Tested by inserting a sleep() in the connection that the UPDATE is waiting
for, and checking that the retry loops a couple of times until the other
connection is done and COMMITs.
- Fixed problem with oqgraph and 'make dist'
Note that after this merge we have a problem show in join_outer where we examine too many rows in one specific case (related to BUG#57024).
This will be fixed when mwl#128 is merged into 5.3.
In case of low memory sort buffer QUICK_INDEX_MERGE_SELECT creates
temporary file where is stores row ids which meet QUICK_SELECT ranges
except of clustered pk range, clustered range is processed separately.
In init_read_record we check if temporary file is used and choose
appropriate record access method. It does not take into account that
temporary file contains partial result in case of QUICK_INDEX_MERGE_SELECT
with clustered pk range.
The fix is always to use rr_quick if QUICK_INDEX_MERGE_SELECT
with clustered pk range is used.
mysql-test/suite/innodb/r/innodb_mysql.result:
test case
mysql-test/suite/innodb/t/innodb_mysql.test:
test case
mysql-test/suite/innodb_plugin/r/innodb_mysql.result:
test case
mysql-test/suite/innodb_plugin/t/innodb_mysql.test:
test case
sql/opt_range.h:
added new method
sql/records.cc:
The fix is always to use rr_quick if QUICK_INDEX_MERGE_SELECT
with clustered pk range is used.
adding new indexes
A fast alter table requires that the existing (old) table
and indices are unchanged (i.e only new indices can be
added). To verify this, the layout and flags of the old
table/indices are compared for equality with the new.
The PACK_KEYS option is a no-op in InnoDB, but the flag
exists, and is used in the table compare. We need to
check this (table) option flag before deciding whether an
index should be packed or not. If the table has
explicitly set PACK_KEYS to 0, the created indices should
not be marked as packed/packable.
If one compiles innodb_plugin, then the tests in suite/innodb_plugin will use the plugin. If not and xtradb is used, the tests will use xtradb.
mysql-test/include/have_innodb_plugin.inc:
Test both for innodb_plugin and xtradb
mysql-test/include/have_real_innodb_plugin.inc:
Test if we are using innodb_plugin (but not xtradb)
mysql-test/include/have_xtradb.inc:
Test if xtradb is used
mysql-test/lib/mtr_cases.pm:
Enable easy testing of innodb_plugin
mysql-test/mysql-test-run.pl:
Added supression for difference between xtradb & innodb_plugin
mysql-test/suite/innodb_plugin/r/innodb-index-ip.result:
Tests from innodb-index that gave different results for innodb_plugin and xtradb
mysql-test/suite/innodb_plugin/r/innodb-index-xb.result:
Tests from innodb-index that gave different results for innodb_plugin and xtradb
mysql-test/suite/innodb_plugin/r/innodb-index.result:
Move tests away that gave different results for innodb_plugin and xtradb
mysql-test/suite/innodb_plugin/r/innodb-ip.result:
Tests from innodb-index that gave different results for innodb_plugin and xtradb
mysql-test/suite/innodb_plugin/r/innodb-xb.result:
Tests from innodb-index that gave different results for innodb_plugin and xtradb
mysql-test/suite/innodb_plugin/r/innodb.result:
Move tests away that gave different results for innodb_plugin and xtradb
mysql-test/suite/innodb_plugin/r/innodb_bug21704-xb.result:
Test result differ for xtradb
mysql-test/suite/innodb_plugin/r/innodb_bug46000.result:
Remove (not needed) error message not given by MariaDB
mysql-test/suite/innodb_plugin/r/innodb_bug49164-xb.result:
Test result differs for xtradb
mysql-test/suite/innodb_plugin/r/innodb_bug49164.result:
Update results
mysql-test/suite/innodb_plugin/r/innodb_bug53591.result:
Remove (not needed) error message not given by MariaDB
mysql-test/suite/innodb_plugin/r/innodb_bug54679.result:
Updated result file
mysql-test/suite/innodb_plugin/r/innodb_mysql.result:
Updated result file
mysql-test/suite/innodb_plugin/t/disabled.def:
Disable some tests that depends on newer version of XtraDB
mysql-test/suite/innodb_plugin/t/innodb-index-ip.test:
Tests from innodb-index that gave different results for innodb_plugin and xtradb
mysql-test/suite/innodb_plugin/t/innodb-index-xb.test:
Tests from innodb-index that gave different results for innodb_plugin and xtradb
mysql-test/suite/innodb_plugin/t/innodb-index.test:
Move tests away that gave different results for innodb_plugin and xtradb
mysql-test/suite/innodb_plugin/t/innodb-ip.test:
Tests from innodb-index that gave different results for innodb_plugin and xtradb
mysql-test/suite/innodb_plugin/t/innodb-xb.test:
Tests from innodb-index that gave different results for innodb_plugin and xtradb
mysql-test/suite/innodb_plugin/t/innodb.test:
Move tests away that gave different results for innodb_plugin and xtradb
mysql-test/suite/innodb_plugin/t/innodb_bug21704-xb.test:
Test result differ for xtradb
mysql-test/suite/innodb_plugin/t/innodb_bug21704.test:
Test result differ for xtradb
mysql-test/suite/innodb_plugin/t/innodb_bug53591.test:
Test results only makes sence for innodb_plugin (things works ok for xtradb)
sql/sql_table.cc:
Don't set HA_CREATE_USED_ROW_FORMAT for create table (only for update_create_info) if ROW_FORMAT is not used.
storage/innodb_plugin/handler/ha_innodb.cc:
Fixed wrong error message from innodb.
This is needed as MariaDB properly handles errors from ha_index_init()
storage/xtradb/handler/ha_innodb.cc:
Update base information for XtraDB so that one can use informationschema.plugins to check if one is using XtraDB
(InnoDB plugin branch)
mysql-test/suite/innodb_plugin/r/innodb_mysql.result:
test case
mysql-test/suite/innodb_plugin/t/innodb_mysql.test:
test case
storage/innodb_plugin/row/row0sel.c:
init null bytes with default values as they might be
left uninitialized in some cases and these uninited bytes
might be copied into mysql record buffer that leads to
valgrind warnings on next use of the buffer.
