The Ultimate Guide to High Availability with MariaDB
This is a read-only copy of the MariaDB Knowledgebase generated on 2024-12-22. For the latest, interactive version please visit https://mariadb.com/kb/.

MariaDB 5.5.28 Changelog

The most recent release in the MariaDB 5.5 series is:
MariaDB 5.5.68 Download Now

Download | Release Notes | Changelog | Overview of 5.5

Release date: 22 Oct 2012

For the highlights of this release, see the release notes.

The revision number links will take you to the revision's page on Launchpad. On Launchpad you can view more details of the revision and view diffs of the code modified in that revision.

  • Revision #3562 Fri 2012-10-19 09:21:35 UTC
    • Fix the incorrect merge
  • Revision #3561 [merge] Thu 2012-10-18 23:33:06 +0200
    • 5.3 merge
    • Revision #2502.567.31 Wed 2012-10-10 22:42:50 +0300
      • Fix of MDEV-3799.
      • Find left table in right join (which turned to left join by reordering tables in join list but phisical order of tables of SELECT left as it was).
    • Revision #2502.567.30 Wed 2012-10-10 09:21:22 +0400
      • Backport of: olav.sandstaa@oracle.com-20120516074923-vd0dhp183vqcp2ql .. into MariaDB 5.3
      • Fix for Bug #12667154 SAME QUERY EXEC AS WHERE SUBQ GIVES DIFFERENT RESULTS ON IN() & NOT IN() COMP #3
      • This bug causes a wrong result in mysql-trunk when ICP is used and bad performance in mysql-5.5 and mysql-trunk.
      • Using the query from bug report to explain what happens and causes the wrong result from the query when ICP is enabled:
        1. The t3 table contains four records. The outer query will read these and for each of these it will execute the subquery.
        2. Before the first execution of the subquery it will be optimized. In this case the important is what happens to the first table t1:
          • make_join_select() will call the range optimizer which decides that t1 should be accessed using a range scan on the k1 index It creates a QUICK_RANGE_SELECT object for this.
          • As the last part of optimization the ICP code pushes the condition down to the storage engine for table t1 on the k1 index.
          • This produces the following information in the explain for this table:
            • 2 DEPENDENT SUBQUERY t1 range k1 k1 5 NULL 3 Using index condition; Using filesort
          • Note the use of filesort.
        3. The first execution of the subquery does (among other things) due to the need for sorting:
          1. Call create_sort_index() which again will call find_all_keys():
          2. find_all_keys() will read the required keys for all qualifying rows from the storage engine. To do this it checks if it has a quick-select for the table. It will use the quick-select for reading records. In this case it will read four records from the storage engine (based on the range criteria). The storage engine will evaluate the pushed index condition for each record.
          3. At the end of create_sort_index() there is code that cleans up a lot of stuff on the join tab. One of the things that is cleaned is the select object. The result of this is that the quick-select object created in make_join_select is deleted.
        4. The second execution of the subquery does the same as the first but the result is different:
          1. Call create_sort_index() which again will call find_all_keys() (same as for the first execution)
          2. find_all_keys() will read the keys from the storage engine. To do this it checks if it has a quick-select for the table. Now there is NO quick-select object(!) (since it was deleted in step 3c). So find_all_keys defaults to read the table using a table scan instead. So instead of reading the four relevant records in the range it reads the entire table (6 records). It then evaluates the table's condition (and here it goes wrong). Since the entire condition has been pushed down to the storage engine using ICP all 6 records qualify. (Note that the storage engine will not evaluate the pushed index condition in this case since it was pushed for the k1 index and now we do a table scan without any index being used). The result is that here we return six qualifying key values instead of four due to not evaluating the table's condition.
          3. As above.
        5. The two last execution of the subquery will also produce wrong results for the same reason.
          • Summary: The problem occurs due to all but the first executions of the subquery is done as a table scan without evaluating the table's condition (which is pushed to the storage engine on a different index). This is caused by the create_sort_index() function deleting the quick-select object that should have been used for executing the subquery as a range scan.
          • Note that this bug in addition to causing wrong results also can result in bad performance due to executing the subquery using a table scan instead of a range scan. This is an issue in MySQL 5.5.
          • The fix for this problem is to avoid that the Quick-select-object that the optimizer created is deleted when create_sort_index() is doing clean-up of the join-tab. This will ensure that the quick-select object and the corresponding pushed index condition will be available and used by all following executions of the subquery.
    • Revision #2502.567.29 Fri 2012-10-05 12:26:55 +0300
      • Fix of MDEV-589.
      • The problem was in incorrect detection of merged views in tem_direct_view_ref::used_tables() .
    • Revision #2502.567.28 Mon 2012-10-01 19:04:17 -0700
      • Added the reported test case for LP bug #823237 (a duplicate of bug #823189).
    • Revision #2502.567.27 Mon 2012-10-01 15:42:49 +0200
      • increase the version
    • Revision #2502.567.26 Sat 2012-09-29 22:44:13 -0700
      • Fixed LP bug #1058071 (MDEV-564).
      • In some rare cases when the value of the system variable join_buffer_size was set to a number less than 256 the function JOIN_CACHE::set_constants determined the size of an offset in the join buffer equal to 1 though the minimal join buffer required more than 256 bytes. This could cause a crash of the server when records from the join buffer were read.
    • Revision #2502.567.25 Fri 2012-09-28 09:54:43 +0200
      • Fix compiler warnings that breaks build (-Werror).
    • Revision #2502.567.24 [merge] Thu 2012-09-27 15:02:17 +0200
      • merge
      • Revision #2502.566.11 [merge] Thu 2012-09-27 12:59:23 +0200
        • Merge from 5.1
        • Revision #2502.565.9 Thu 2012-09-27 12:25:45 +0200
          • Fix incorrect assembler in Taocrypt which causes crashes on i386 with certain GCC versions/options
      • Revision #2502.566.10 [merge] Wed 2012-09-26 18:49:38 +0200
        • merge
        • Revision #2502.565.8 Wed 2012-09-26 11:59:49 +0200
          • always force the language in mysql_install_db
      • Revision #2502.566.9 Tue 2012-09-25 20:23:01 +0200
        • a simple pam user mapper module
      • Revision #2502.566.8 [merge] Wed 2012-09-26 18:29:49 +0200
        • Merge from 5.1.
        • Revision #2502.565.7 Wed 2012-09-26 15:30:08 +0200
          • Fix some failures in 5.1 Buildbot:
            • Fix some warnings in newer GCC (-Werror ...).
            • Fix wrong STACK_DIRECTION detected by configure due to compiler inlining.
    • Revision #2502.567.23 Thu 2012-09-27 13:18:07 +0500
      • MDEV-495 backport --ignore-db-dir.
      • The feature was backported from MySQL 5.6.
      • Some code was added to make commands as
        • SELECT * FROM ignored_db.t1;
        • CALL ignored_db.proc();
        • USE ignored_db;
      • to take that option into account.
      • per-file comments:
        • mysql-test/r/ignore_db_dirs_basic.result
          • test result added.
        • mysql-test/t/ignore_db_dirs_basic-master.opt
          • options for the test,
          • actually the set of --ignore-db-dir lines.
        • mysql-test/t/ignore_db_dirs_basic.test
          • test for the feature.
          • Same test from 5.6 was taken as a basis,
          • then tests for SELECT, CALL etc were added.
      • per-file comments:
        • sql/mysql_priv.h
          • MDEV-495 backport --ignore-db-dir.
          • interface for db_name_is_in_ignore_list() added.
        • sql/mysqld.cc
          • MDEV-495 backport --ignore-db-dir.
          • --ignore-db-dir handling.
        • sql/set_var.cc
          • MDEV-495 backport --ignore-db-dir.
          • the @@ignore_db_dirs variable added.
        • sql/sql_show.cc
          • MDEV-495 backport --ignore-db-dir.
          • check if the directory is ignored.
        • sql/sql_show.h
          • MDEV-495 backport --ignore-db-dir.
          • interface added for opt_ignored_db_dirs.
        • sql/table.cc
          • MDEV-495 backport --ignore-db-dir.
          • check if the directory is ignored.
    • Revision #2502.567.22 [merge] Mon 2012-09-24 17:29:26 +0200
    • Revision #2502.567.21 Thu 2012-09-20 12:48:59 +0300
      • MDEV-521 fix.
      • After pullout item during single row subselect transformation it should be fixed properly.
  • Revision #3560 Thu 2012-10-18 11:30:29 +0200
    • do not print return address when callstack is output on Windows, it does not provide any useful info
  • Revision #3559 Thu 2012-10-18 11:19:28 +0200
    • Do not DBUG_PRINT uninitialized variable. This avoid false positive from runtime checks in debug builds (Windows).
  • Revision #3558 Wed 2012-10-17 19:04:08 +0200
    • RPM fixes:
    • shared should provide libmysqlclient.so.18(libmysqlclient_16) too
    • don't "use DBD::mysql" explicitly in mytop
  • Revision #3557 [merge] Tue 2012-10-16 13:04:42 +0200
    • mysql-5.5.28
  • Revision #3556 [merge] Tue 2012-10-16 10:36:28 +0200
    • XtraDB 1.1.8-29.0
    • Revision #0.12.56 Fri 2012-10-12 17:40:06 +0200
      • Percona-Server-5.5.27-rel29.0
  • Revision #3555 Tue 2012-10-16 10:35:05 +0200
    • minor test cleanup. one server restart less in mtr
  • Revision #3554 Tue 2012-10-16 10:34:38 +0200
    • a typo caused plugins to have no MYSQL_SERVER symbol defined.
    • don't try to define it for plugins, then, as they don't need it.
  • Revision #3553 Fri 2012-10-12 18:15:38 +0200
    • simplify future xtradb merges (hopefully)
  • Revision #3552 Fri 2012-10-12 16:44:54 +0300
    • MDEV-435: Expensive subqueries may be evaluated during optimization in merge_key_fields
    • Fix by Sergey Petrunia.
    • This patch only prevents the evaluation of expensive subqueries during optimization.
    • The crash reported in this bug has been fixed by some other patch.
    • The fix is to call value->is_null() only when !value->is_expensive(), because is_null() may trigger evaluation of the Item, which in turn triggers subquery evaluation if the Item is a subquery.
  • Revision #3551 Fri 2012-10-12 10:54:46 +0200
    • MDEV-3802. Millisecond timeout support in non-blocking client library.
    • In 10.0, VIO timeouts can be in milliseconds, so we add a new function mysql_get_timeout_value_ms() which can return millisecond-precision timeout values.
    • In 5.5, we do not have millisecond precision for timeouts. But we still provide the mysql_get_timeout_value_ms() function; this makes it easier for applications as they can use the millisecond function in 10.0 and still work with the 5.5 version of the client library.
  • Revision #3550 Thu 2012-10-11 12:09:21 +0300
    • MDEV-3804:
    • MySQL fix for bug#11765413 removed (we have better and more general fix for the problem).
    • Test suite added.
  • Revision #3549 Mon 2012-10-08 13:06:20 +0200
    • sort status variables
  • Revision #3548 Fri 2012-10-05 14:24:38 +0200
  • Revision #3547 Mon 2012-10-01 16:12:15 +0200
    • increase the version
  • Revision #3546 Mon 2012-10-01 16:11:46 +0200
    • update the r/mysqld--help,win.rdiff to match the updated r/mysqld--help.result
  • Revision #3545 Mon 2012-10-08 13:56:57 +0200
    • MDEV-519: mariadb-client-5.5 conflicts with package mytop
    • Do not include mytop in mariadb-client-5.5 .deb package.
    • There is already a Debian mytop package, so we get a package conflict. And there is no reason for the MariaDB project to guerrilla-take-over mytop maintenance.
  • Revision #3544 Thu 2012-10-04 23:52:11 +0300
    • Fixed issues found by buildbot & valgrind:
      • Wrong thd uses in Item_subselect, could lead to crash
      • Inititalize uninitialized variable in new autoincrement handling code
  • Revision #3543 Tue 2012-10-02 16:26:22 +0300
    • Fixed installation issues on debian:
      • Don't abort if plugin table exists
      • Use longer timeout for start/stop of mysqld
  • Revision #3542 Tue 2012-09-25 13:45:11 +0300
    • makes mi_test_all.sh & ma_test_all.sh working (MDEV-285)
  • Revision #3541 Tue 2012-09-25 00:46:54 +0200
    • MDEV-546 : error when compiling client library - incorrect client_settings.h
    • Remove sql directory from the include path to workaround the problem. This removes the ambiguity , since then only one client_settings.h will be in the include paths
  • Revision #3540 Sat 2012-09-22 14:19:02 +0300
    • Updated mytop to version 1.91
    • Fixed that 'Handler:' output gives correct result with MariaDB (not including temporary tables)
  • Revision #3539 Fri 2012-09-21 15:03:38 +0200
    • Fix test failure on --embedded-server
  • Revision #3538 Tue 2012-09-18 23:34:16 +0300
    • This fix+comments was originally made by Alexey Kopytov
    • Bug #1035225 / MySQL bug #66301: INSERT ... ON DUPLICATE KEY UPDATE + innodb_autoinc_lock_mode=1 is broken
    • The problem was that when certain INSERT ... ON DUPLICATE KEY UPDATE were executed concurrently on a table containing an AUTO_INCREMENT column as a primary key, InnoDB would correctly reserve non-overlapping AUTO_INCREMENT intervals for each statement, but when the server encountered the first duplicate key error on the secondary key in one of the statements and performed an UPDATE, it also updated the internal AUTO_INCREMENT value to the one from the existing row that caused a duplicate key error, even though the AUTO_INCREMENT value was not specified explicitly in the UPDATE clause. It would then proceed with using AUTO_INCREMENT values the range reserved previously by another statement, causing duplicate key errors on the AUTO_INCREMENT column.
    • Fixed by changing write_record() to ensure that in case of a duplicate key error the internal AUTO_INCREMENT counter is only updated when the AUTO_INCREMENT value was explicitly updated by the UPDATE clause. Otherwise it is restored to what it was before the duplicate key error, as that value is unused and can be reused for subsequent successfully inserted rows.
  • Revision #3537 [merge] Tue 2012-09-18 15:32:08 +0300
    • Automatic merge
    • Revision #3533.1.2 Tue 2012-09-18 15:14:19 +0300
      • Fix for MDEV-533: Confusing error code when doing auto-increment insert for out-of-range values
        • create table t1 (a smallint primary key auto_increment);
          • insert into t1 values(32767);
          • insert into t1 values(NULL);
          • ERROR 1062 (23000): Duplicate entry '32767' for key 'PRIMARY
        • Now on always gets error HA_ERR_AUTOINC_RANGE=167 "Out of range value for column", independent of store engine, SQL Mode or number of inserted rows. This is an unique error that is easier to test for in replication.
        • Another bug fix is that we now get an error when trying to insert a too big auto-generated value, even in non-strict mode.
          • Before one get insted the max column value inserted.
          • This patch also fixes some issues with inserting negative numbers in an auto-increment column.
          • Fixed the ER_DUP_ENTRY and HA_ERR_AUTOINC_ERANGE are compared the same between master and slave.
          • This ensures that replication works between an old server to a new slave for auto-increment overflow errors.
          • Added SQLSTATE errors for handler errors
        • Smaller bug fixes:
          • Added warnings for duplicate key errors when using INSERT IGNORE
          • Fixed bug when using --skip-log-bin followed by --log-bin, which did set log-bin to "0"
          • Allow one to see how cmake is called by using --just-print --just-configure
    • Revision #3533.1.1 Thu 2012-09-13 21:11:47 +0300
      • Added THD::utime_after_query to avoid calling current_utime() twice for every end-of-query
      • Increment long_query_count also if thd->variables.log_slow_rate_limit is used
      • Added new state "Writing to binlog"
  • Revision #3536 Tue 2012-09-18 15:31:21 +0300
    • Fixed test for ps-protocol
  • Revision #3535 [merge] Tue 2012-09-18 13:42:06 +0300
    • Merged the fix for Bug #1009187, MDEV-373
    • Revision #2502.567.20 [merge] Mon 2012-09-17 11:13:46 +0300
      • Merged the fix for Bug #1009187, MDEV-373.
      • Performed some refactoring and simplification that was enabled and required by the merge.
      • Revision #2502.566.6 Fri 2012-09-14 11:26:01 +0300
        • Fix Bug #1009187, MDEV-373, mysql bug#58628
        • Analysis:
          • The queries in question use the [unique | index]_subquery execution methods. These methods reuse the ref keys constructed by create_ref_for_key(). The way create_ref_for_key() works is that it doesn't store in ref.key_copy[] store_key elements that represent constants. In particular it doesn't store the store_key for NULL constants.
          • The execution of [unique | index]_subquery calls subselect_uniquesubquery_engine::copy_ref_key, which in addition to copy the left IN argument into a index lookup key, is supposed to detect if the left IN argument contains NULLs. Since the store_key for the NULL constant is not copied into the key array, the null is not detected, and execution erroneously proceeds as if it should look for a complete match.
        • Solution:
          • The solution (unlike MySQL) is to reuse already computed information about NULL presence. Item_in_optimizer::val_int already finds out if the left IN operand contains NULLs. The fix propagates this to the execution methods subselect_[unique | index]subquery_engine::exec so it knows if there were NULL values independent of the presence of keys.
          • In addition the patch siplifies copy_ref_key() and the logic that hanldes the case of NULLs in the left IN operand.
    • Revision #2502.567.19 Fri 2012-09-07 09:39:51 +0300
      • Fix of MDEV-511.
      • As far as we reopen tables so TABLE become invalid we should remove the pointer on cleanup().
  • Revision #3534 Tue 2012-09-18 00:42:05 +0300
    • Fixed issues in test suite when running with --ps-protocol
  • Revision #3533 Mon 2012-09-10 17:26:54 +0300
    • Fixed random test failure
  • Revision #3532 Mon 2012-09-10 16:46:33 +0300
    • Fixed Bug#1002564: Wrong result for a lookup query from a heap table
  • Revision #3531 Mon 2012-09-10 13:53:19 +0300
    • Fixed compiler warning on Mac
  • Revision #3530 Sun 2012-09-09 01:22:06 +0300
    • Added new status variables:
      • feature_dynamic_columns,feature_fulltext,feature_gis,feature_locale,feature_subquery,feature_timezone,feature_trigger,feature_xml Opened_views, Executed_triggers, Executed_events
      • Added new process status 'updating status' as part of 'freeing items'
  • Revision #3529 [merge] Sun 2012-09-09 00:38:15 +0300
    • Automatic merge
    • Revision #3521.1.2 Fri 2012-09-07 17:05:17 +0300
      • Better error message when using --language or --log-bin
      • Simplify code
    • Revision #3521.1.1 Wed 2012-09-05 18:23:51 +0300
      • Added function last_value() which returns the last value but evalutes all arguments as a side effect.
      • Original patch by Eric Herman
  • Revision #3528 Fri 2012-09-07 09:17:31 +0300
    • Fix of MDEV-511.
    • As far as we reopen tables so TABLE become invalid we should remove the pointer on cleanup().
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.