on select from I_S.INNODB_CHANGED_PAGES
Analysis: limit_lsn_range_from_condition() incorrectly parses
start_lsn and/or end_lsn conditions.
Fix from SergeyP. Added some test cases.
- Change the default flag value to ON.
- Update the testcases to be run extended_keys=ON:
= trivial test result updates
= If extended_keys setting makes a difference for a testcase, run the testcase
with extended_keys=off. There were only a few such cases
- Update to vcol_select_innodb looks like a worse plan but it will be gone in 10.0.
FAILING ASSERTION: FLEN == LEN
Problem:
Broken invariant triggered when building a unique index on a
binary column and the input data contains duplicate keys. This was broken
in debug builds only.
Fix:
Fixed length of the binary datatype can be greater than length of
the shorter prefix on which index is being created.
mysql-test/suite/innodb/r/row_lock.result:
Test case for MDEV-5629
mysql-test/suite/innodb/t/row_lock.test:
Test case for MDEV-5629
sql/filesort.cc:
Don't call unlock_row() in case of errors
Problem:
In the clustered index, when an update operation is done the overall
scenario (after rb#4479) is as follows:
1. Delete mark the old record that is to be updated.
2. The old record disowns the blobs.
3. Insert the new record into clustered index.
4. For non-updated blobs, new record must own it. Verified by assert.
5. For non-updated blobs, in new record marked as inherited.
Scenario involving DB_LOCK_WAIT:
If step 3 times out, then we will skip 1 and 2 and will continue from
step 3. This skipping is achieved by the UPD_NODE_INSERT_BLOB state.
In this case, step 4 is not correct. Because of step 1, the new
record need not own the blobs. Hence the assert failure.
Solution:
The assert in step 4 is removed. Instead code is added to ensure that
the record owns the blob.
Note:
This is a regression caused by rb#4479.
rb#4571 approved by Marko
AUTO_INCREMENT_INCREMENT
Problem:
=======
When auto_increment_increment system variable decreases,
immediate next value of auto increment column is not affected.
Solution:
========
Get the previous inserted value of auto increment column by
subtracting the previous auto_increment_increment from next
auto increment value. After that calculate the current autoinc value
using newly changed auto_increment_increment variable.
Approved by Sunny [rb#4394]
Syntax. Server support. Test cases.
InnoDB bugfixes:
* don't mess around with system sprintf's, always use my_error() for errors.
* don't use InnoDB internal error codes where OS error codes are expected.
* don't say "file not found", when it was.
Update InnoDB to 5.6.14
Apply MySQL-5.6 hack for MySQL Bug#16434374
Move Aria-only HA_RTREE_INDEX from my_base.h to maria_def.h (breaks an assert in InnoDB)
Fix InnoDB memory leak
Problem:
The function row_upd_changes_ord_field_binary() is used to decide whether to
use row_upd_clust_rec_by_insert() or row_upd_clust_rec(). The function
row_upd_changes_ord_field_binary() does not make use of charset information.
Based on binary comparison it decides that r1 and r2 differ in their ordering
fields.
In the function row_upd_clust_rec_by_insert(), an update is done by delete +
insert. These operations internally make use of cmp_dtuple_rec_with_match()
to compare records r1 and r2. This comparison takes place with the use of
charset information.
This means that it is possible for the deleted record to be reused in the
subsequent insert. In the given scenario, the characters 'a' and 'A' are
considered equal in the my_charset_latin1. When this happens, the ownership
information of externally stored blobs are not correctly handled.
Solution:
When an update is done by delete followed by insert, disown the relevant
externally stored fields during the delete marking itself (within the same
mtr). If the insert succeeds, then nothing with respect to blob ownership
needs to be done. If the insert fails, then the disown done earlier will be
removed when the operation is rolled back.
rb#4479 approved by Marko.
support ha_innodb.so as a dynamic plugin.
* remove obsolete *,innodb_plugin.rdiff files
* s/--plugin-load=/--plugin-load-add=/
* MYSQL_PLUGIN_IMPORT glob_hostname[]
* use my_error instead of push_warning_printf(ER_DEFAULT)
* don't use tdc_size and tc_size in a module
update test cases (XtraDB is 5.6.14, InnoDB is 5.6.10)
* copy new tests over
* disable some tests for (old) InnoDB
* delete XtraDB tests that no longer apply
small compatibility changes:
* s/HTON_EXTENDED_KEYS/HTON_SUPPORTS_EXTENDED_KEYS/
* revert unnecessary InnoDB changes to make it a bit closer to the upstream
fix XtraDB to compile on Windows (both as a static and a dynamic plugin)
disable XtraDB on Windows (deadlocks) and where no atomic ops are available (e.g. CentOS 5)
storage/innobase/handler/ha_innodb.cc:
revert few unnecessary changes to make it a bit closer to the original InnoDB
storage/innobase/include/univ.i:
correct the version to match what it was merged from
Fix :
-------
Created separate suites called innodb_zip ans i_innodb_zip that contain all compression tests.
Running the new suites with following compression-related parameters :
* innodb_compression_level = {1/9}
* innodb_log_compressed_pages = {ON/OFF}
restore old innodb get_innobase_type_from_mysql_type() function,
record all mysql_type->innodb_type mapping
(as generated by mysql-5.6).
add safety code to disable online alter when internal types don't match
storage/innobase/dict/dict0stats.cc:
revert to 5.6 state
- Character set code & tests from Alexander Barkov
- Integration with ALTER TABLE, REPAIR and open_table from Monty
The problem was that MySQL 5.6 added some croatian and vitanamese character set collations that are incompatible with MariaDB.
The fix is to move the MariaDB conflicting collation numbers out of the region that MySQL is likely to use.
mysql_upgrade, REPAIR TABLE or ALTER TABLE will fix the collations.
If one tries to access and old incompatible table, one will get the error "Table upgrade required...."
After this patch, MariaDB supports all the MySQL character set collations and the old MariaDB croatian collations, which are closer to the latest standard than the MySQL versions.
New character sets:
ucs2_croatian_mysql561_uca_ci
utf8_croatian_mysql561_uca_ci
utf16_croatian_mysql561_uca_ci
utf32_croatian_mysql561_uca_ci
utf8mb4_croatian_mysql561_uca_ci
Other things:
- Fixed some compiler warnings
- mysql_upgrade prints information about repaired tables.
- Increased version number
VERSION:
Increased VERSION number
client/mysqlcheck.c:
Print repaired table name when using --verbose
include/m_ctype.h:
Add new MariaDB collation regions that are not likely to conflict with MySQL
include/my_base.h:
Added flag to detect if table was opened for ALTER TABLE
mysql-test/r/ctype_ldml.result:
Updated result
mysql-test/r/ctype_uca.result:
Updated result
mysql-test/r/ctype_upgrade.result:
Updated result
mysql-test/r/ctype_utf16_uca.result:
Updated result
mysql-test/r/ctype_utf32_uca.result:
Updated result
mysql-test/r/ctype_utf8mb4_uca.result:
Updated result
mysql-test/std_data/ctype_upgrade:
Test files for testing upgrading of conflicting collations
mysql-test/suite/engines/funcs/r/db_alter_collate_ascii.result:
New collations added
mysql-test/suite/engines/funcs/r/db_alter_collate_utf8.result:
New collations added
mysql-test/suite/innodb/r/innodb_ctype_ldml.result:
Updated test result
mysql-test/suite/innodb/t/innodb_ctype_ldml.test:
Updated test result
mysql-test/suite/plugins/r/show_all_plugins.result:
Updated version number
mysql-test/suite/roles/create_and_drop_role_invalid_user_table.result:
Updated version number
mysql-test/t/ctype_ldml.test:
Updated test
mysql-test/t/ctype_uca.test:
Testing of new collations
mysql-test/t/ctype_upgrade.test:
Testing of upgrading tables with old collations
The test ensures that:
- We will get an error if we try to open a table with old collations.
- CHECK TABLE will detect that the table needs to be upgraded.
- ALTER TABLE and REPAIR will fix the table.
- mysql_upgrade works as expected
mysql-test/t/ctype_utf16_uca.test:
Testing of new collations
mysql-test/t/ctype_utf32_uca.test:
Testing of new collations
mysql-test/t/ctype_utf8mb4_uca.test:
Testing of new collations
mysys/charset-def.c:
Added new character sets
mysys/charset.c:
Always give an error, if requested, if a character set didn't exist
sql/handler.cc:
- Added upgrade_collation() to check if collation is compatible with old version
- check_collation_compatibility() checks if we are using an old collation from MariaDB 5.5 or MySQL 5.6
- ha_check_for_upgrade() returns HA_ADMIN_NEEDS_ALTER if we have an incompatible collation
sql/handler.h:
Added new prototypes
sql/sql_table.cc:
- Mark that tables are opened for ALTER TABLE
- If table needs to be upgraded, ensure we are not using online alter table.
sql/table.cc:
- If we are using an old incompatible collation, change to use the new one and mark table as incompatible.
- Give an error if we try to open an incompatible table.
sql/table.h:
Added error that table needs to be rebuild
storage/connect/ha_connect.cc:
Fixed compiler warning
strings/ctype-uca.c:
New character sets
The merge is still missing a few hunks related to temporary tables and
InnoDB log file size. The associated code did not seem to exist in
10.0, so the merge of that needs more work. Until this is fixed, there
are a number of test failures as a result.
For compatibility purposes let InnoDB use DATA_INT for MYSQL_TYPE_ENUM and MYSQL_TYPE_SET.
Silence the warning for these types and let the index translation table to be built anyway.
Test case by Jeremy Cole.
INDEX_READ_MAP HAD NO MATCH
If index_read_map is called for exact search and no matching records
exists it will position the cursor on the next record, but still having the
relative position to BTR_PCUR_ON.
This will make a call for index_next to read yet another next record,
instead of returning the record the cursor points to.
Fixed by setting pcur->rel_pos = BTR_PCUR_BEFORE if an exact
[prefix] search is done, but failed.
Also avoids optimistic restoration if rel_pos != BTR_PCUR_ON,
since btr_cur may be different than old_rec.
rb#3324, approved by Marko and Jimmy
