MariaDB 5.3.4 Changelog

Downloadarrow-up-right |Release Notes |Changelog |Overview of 5.3arrow-up-right

Release date: 15 Feb 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 #3421arrow-up-right Tue 2012-02-14 16:52:56 +0200

    • Fix for Bug #910123arrow-up-right MariaDB 5.3.3 causes 1093 error on Drupal

    • Problem was that now we can merge derived table (subquery in the FROM clause).

    • Fix: in case of detected conflict and presence of derived table "over" the table which cased the conflict - try materialization strategy.

  • Revision #3420arrow-up-right Tue 2012-02-14 16:04:06 +0400

  • Revision #3419arrow-up-right [merge] Tue 2012-02-14 14:13:10 +0400

  • Revision #3418arrow-up-right Mon 2012-02-13 23:46:57 -0800

    • If the flag 'optimize_join_buffer_size' is set to 'off' and the value of the system variable 'join_buffer_size' is greater than the value of the system variable 'join_buffer_space_limit' than no join cache can be employed to join tables of the executed query.

    • A bug in the function JOIN_CACHE::alloc_buffer allowed to use join buffer even in this case while another bug in the function revise_cache_usage could cause a crash of the server in this case if the chosen execution plan for the query contained outer join or semi-join operation.

  • Revision #3417arrow-up-right Mon 2012-02-13 17:14:10 +0100

    • When we fail during slave thread initialisation, keep mi->run_lock locked until we have finished clean up.

    • Previously, the code released the lock without marking that the thread was running. This allowed a new slave thread to start while the old one was still in the middle of cleaning up, causing assertions and probably general mayhem.

  • Revision #3416arrow-up-right [merge] Sun 2012-02-12 23:03:36 +0100

  • Revision #3415arrow-up-right [merge] Sat 2012-02-11 15:00:15 +0100

    • merge

    • Revision #2732.52.1arrow-up-right [merge] Sat 2012-02-11 14:57:44 +0100

      • Fix for MDEV-140arrow-up-right, Bug #930145arrow-up-right - broken SSL connectivity for some connectors

      • Revision #2643.150.3arrow-up-right Sat 2012-02-11 03:25:49 +0100

        • A recent change in the server protocol code broke SSL connection for some client libraries.

        • Protocol documentation (MySQL_Internals_ClientServer_Protocolarrow-up-right) says that initial packet sent by client if client wants SSL, consists of client capability flags only (4 bytes or 2 bytes edependent on protocol versionl).

        • Some clients happen to send more in the initial SSL packet (C client, Python connector), while others (Java, .NET) follow the docs and send only client capability flags.

        • A change that broke Java client was a newly introduced check that frst client packet has 32 or more bytes. This is generally wrong, if client capability flags contains CLIENT_SSL.

        • Also, fixed the code such that read max client packet size and charset in the first packet prior to SSL handshake. With SSL, clients do not have to send this info, they can only send client flags.

        • This is now fixed such that max packet size and charset are not read prior to SSL handshake, in case of SSL they are read from the "complete" client authentication packet after SSL initialization.

  • Revision #3414arrow-up-right [merge] Fri 2012-02-10 22:09:57 +0100

  • Revision #3413arrow-up-right [merge] Fri 2012-02-10 22:56:34 +0200

  • Revision #3412arrow-up-right Thu 2012-02-09 23:35:26 +0200

  • Revision #3411arrow-up-right Fri 2012-02-03 12:49:17 -0800

    • Made mrr related counters temporarily invisible until we agree upon their names.

  • Revision #3410arrow-up-right Fri 2012-02-03 16:56:12 +0200

    • Fixed typos in Query Cache.

  • Revision #3409arrow-up-right [merge] Fri 2012-02-03 13:32:29 +0200

    • Merge with 5.2

    • Revision #2732.46.69arrow-up-right Fri 2012-02-03 12:24:55 +0200

      • Fixed DELETE issues of view over view over table.

      • Revision #2732.46.68arrow-up-right Fri 2012-02-03 10:31:30 +0200

        • Added 5.2 test result delimiter

        • Revision #2732.46.67arrow-up-right Fri 2012-02-03 10:28:23 +0200

          • Fix check of view updatability in case of underlying view changes its updatability.

          • For single table update/insert added deep check of single tables (single_table_updatable()). For multi-table view insert added additional check of target table (check_view_single_update).

          • Multi-update was correct.

          • Test suite for all cases added.

  • Revision #3408arrow-up-right Fri 2012-02-03 13:01:05 +0200

  • Revision #3407arrow-up-right Fri 2012-02-03 00:46:34 -0800

    • Back-ported the fix for bug #12831587 from mysql-5.6 code line.

    • The comment for the fix commit says:

      • Due to the changes required by ICP we first copy a row from the InnoDB format to the MySQL row buffer and then copy it to the pre-fetch queue. This was done for the non-ICP code path too. This change removes the double copy for the latter.

  • Revision #3406arrow-up-right Thu 2012-02-02 22:22:27 -0800

    • Applied the patch from mysql-5.6 code line that fixed a significant performance drop for high concurrency bechmarks (bug #11765850

  • Here's the comment of the patch commit:

    • The bug is that the InnoDB pre-fetch cache was not being used in row_search_for_mysql(). Secondly the changeset that planted the bug also introduced some inefficient code. It would read an extra row, convert it to MySQL row format (for ICP==off), copy the row to the pre-fetch cache row buffer, then check for cache overflow and dequeue the row that was pushed if there was a possibility of a cache overflow.

  • Revision #3405arrow-up-right [merge] Wed 2012-02-01 17:48:45 -0800

  • Revision #3404arrow-up-right Wed 2012-02-01 17:09:49 +0200

    • Problem was in try to check/use Item_direct_ref of derived view when we have to use real Item_field under it.

  • Revision #3403arrow-up-right Tue 2012-01-31 21:12:26 +0100

    • sort status variables alphabetically in mysqld.cc

  • Revision #3402arrow-up-right Mon 2012-01-30 20:34:47 +0400

    • Bug #923246arrow-up-right: Loosescan reports different result than other semijoin methods

    • 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).

  • Revision #3401arrow-up-right [merge] Mon 2012-01-30 17:38:14 +0400

    • Merge fix for Bug #922254arrow-up-right

      • Revision #3397.1.1arrow-up-right Fri 2012-01-27 17:35:26 +0400

        • Bug #922254arrow-up-right: Assertion `0' failed at item_cmpfunc.cc:5899: Item* Item_equal::get_first(JOIN_TAB*, Item*)

        • 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.

  • Revision #3400arrow-up-right Sat 2012-01-28 01:12:45 -0800

    • Applied the fix for bug #12546542 from the mysql-5.6 code line:

    • JOIN_CACHE::join_records forgot to reset JOIN_TAB::first_unmatched in some cases.

  • Revision #3399arrow-up-right [merge] Fri 2012-01-27 19:23:08 -0800

    • Merge.

    • Revision #3393.1.1arrow-up-right Fri 2012-01-27 19:01:26 -0800

      • Back-ported test cases for MySQL Bug #59919arrow-up-right of mysql-5.6 code line. The bug could not be reproduced in the latest release of mariadb-5.3 as it was fixed by Sergey Petrunia when working on the problems concerning outer joins within in subqueries converted to semi-joins.

  • Revision #3398arrow-up-right Fri 2012-01-27 17:51:40 +0400

    • Make testcase stable by adding --sorted_result for SHOW STATUS commands.

  • Revision #3397arrow-up-right Thu 2012-01-26 14:20:34 +0400

    • Fix compile failure when built without query cache: define QUERY_CACHE_DB_LENGTH_SIZE 0, just like it is done with QUERY_CACHE_FLAGS_SIZE.

  • Revision #3396arrow-up-right Thu 2012-01-26 12:22:02 +0400

    • Sort counters by name (will this make them show in the same order on all platforms?)

  • Revision #3395arrow-up-right Wed 2012-01-25 22:05:20 +0400

    • Bug #920713arrow-up-right: Wrong result (missing rows) with firstmatch+BNL, IN subquery, ...

      • 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.

  • Revision #3394arrow-up-right [merge] Wed 2012-01-25 18:36:57 +0400

    • Merge

    • Revision #3390.1.3arrow-up-right Wed 2012-01-25 18:33:57 +0400

      • Bug #920255arrow-up-right: Wrong result (extra rows) with loosescan and IN subquery

      • 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#.

    • Revision #3390.1.2arrow-up-right Wed 2012-01-25 18:27:34 +0400

      • Update handler status variables after the last commit.

    • Revision #3390.1.1arrow-up-right Mon 2012-01-23 23:35:52 +0400

      • Add MRR counters: Handler_mrr_init, Handler_mrr_extra_rowid_sorts, Handler_mrr_extra_key_sorts.

  • Revision #3393arrow-up-right Mon 2012-01-23 15:14:13 +0200

    • Fixed creating limit for exists subquery.

  • Revision #3392arrow-up-right Sun 2012-01-22 12:54:30 -0800

  • Revision #3391arrow-up-right Sat 2012-01-21 20:58:23 -0800

  • Revision #3390arrow-up-right Fri 2012-01-20 02:11:53 +0400

    • Bug #912513arrow-up-right: Wrong result (missing rows) with join_cache_hashed+materialization+semijoin=on

    • equality substitution code was geared towards processing WHERE/ON clauses. that is, it assumed that it was doing substitions on the code that

      • wasn't attached to any particular join_tab yet

      • was going to be fed to make_join_select() which would take the condition apart and attach various parts of it to tables inside/outside semi-joins.

    • However, somebody added equality substition for ref access. That is, if we have a ref access on TBL.key=expr, they would do equality substition in 'expr'. This possibility wasn't accounted for.

    • Fixed equality substition code by adding a mode that does equality substition under assumption that the processed expression will be attached to a certain particular table TBL.

  • Revision #3389arrow-up-right Thu 2012-01-19 23:44:43 +0400

    • Bug #912538arrow-up-right: Wrong result (missing rows) with semijoin=on, firstmatch=on, ...

      • setup_semijoin_dups_elimination() would incorrectly set join_tab->do_firstmatch when the join order had outer tables interleaved with inner.

  • Revision #3388arrow-up-right Thu 2012-01-19 13:46:59 +0100

    • Fix compiler warning on Windows.

  • Revision #3387arrow-up-right [merge] Wed 2012-01-18 15:28:13 -0800

    • Merge

      • Revision #3384.1.1arrow-up-right [merge] Wed 2012-01-18 14:19:28 -0800

        • Merge

        • Revision #3381.1.1arrow-up-right Wed 2012-01-18 03:31:20 -0800

          • If the expression for a derived table of a query contained a LIMIT clause the estimate of the number of rows in this derived table returned by the EXPLAIN command could be badly off since the optimizer ignored the limit number from the LIMIT clause when getting the estimate.

          • The call of the method SELECT_LEX_UNIT->set_limit added in the code of mysql_derived_optimize() will be needed also in maria-5.5 where parameters in the LIMIT clause are supported.

  • Revision #3386arrow-up-right Wed 2012-01-18 14:52:56 +0100

    • multi-delete should ignore semi-join internal temp tables, when looking for tables to delete from

  • Revision #3385arrow-up-right [merge] Wed 2012-01-18 14:52:38 +0100

  • Revision #3384arrow-up-right Wed 2012-01-18 12:53:50 +0200

    • Adjust test results after Monty's push of the new handler counter Handler_read_rnd_deleted.

  • Revision #3383arrow-up-right Tue 2012-01-17 15:16:00 +0200

    • Removed unused code merged from 5.2. In 5.3 we fix this problem by checking if we put max/min group function without GROUP BY artificially in case of MODE_ONLY_FULL_GROUP_BY sql mode.

  • Revision #3382arrow-up-right Fri 2012-01-13 14:35:49 +0200

    • Added Handler_read_rnd_deleted, number of deleted rows found with ha_read_rnd_first.

  • Revision #3381arrow-up-right Wed 2012-01-11 10:35:16 +0200

    • Fix the comment.

  • Revision #3380arrow-up-right Tue 2012-01-10 23:26:00 +0200

    • Fix for Bug #908269arrow-up-right Wrong result with subquery in select list, EXISTS, constant MyISAM/Aria table.

    • Problem: When building the condition for JOIN::outer_ref_cond the optimizer forgot to take into account that this condition could depend on constant tables as well.

  • Revision #3379arrow-up-right [merge] Tue 2012-01-10 18:20:56 +0400

  • Revision #3378arrow-up-right Mon 2012-01-09 13:49:47 +0200

    • Fixed that --sorted-result in mysql-test-run also works for exec

  • Revision #3377arrow-up-right Sun 2012-01-08 21:14:07 +0100

    • MDEV-77arrow-up-right - possible deadlock in XtraDB async io subsystem on Windows.

    • Split IO threads into ones that handle only read completion and ones that handle only write completion, as it was originally done, but got lost with "completion port" patch. The reason we need to have dedicated read and dedicated write threads is that read completion routine can block waiting for write io to complete, and in rare cases where all io threads are handling async reads, it can deadlock.

  • Revision #3376arrow-up-right Mon 2012-01-02 20:06:36 -0800

  • Revision #3375arrow-up-right Fri 2011-12-30 22:19:05 +0100

    • Make test results stable.

  • Revision #3374arrow-up-right Fri 2011-12-30 20:22:52 +0100

    • Update version in configure.in (was forgotten in 5.3.3 release).

  • Revision #3373arrow-up-right Fri 2011-12-30 11:34:29 +0100

    • Continuation of the efforts in previous cset.

  • Revision #3372arrow-up-right Thu 2011-12-29 22:29:02 +0100

    • Make test results stable (they weren't, because filesort() used to read from a heap temptable, which uses pointers to records (that is, byte* pointers) as rowids.

    • This meant that for rows with the same sort key value, the order was determined by memory layout.

  • Revision #3371arrow-up-right Wed 2011-12-28 12:12:48 +0400

    • Update test results.

  • Revision #3370arrow-up-right [merge] Wed 2011-12-28 03:37:34 +0400

    • Merge

    • Revision #3364.1.1arrow-up-right Tue 2011-12-20 00:55:32 +0400

      • Bug #906357arrow-up-right: Incorrect result with outer join and full text match

        • The problem was that const-table-reading code would try to evaluate MATCH() before init_ftfuncs() was called.

        • Fixed by making MATCH function "expensive" so that nobody tries to evaluate it at optimization phase.

  • Revision #3369arrow-up-right Sun 2011-12-25 18:03:03 -0800

    • Changed a test case from join_cache.test to make it platform independent.

  • Revision #3368arrow-up-right Sat 2011-12-24 08:55:10 -0800

    • Back-ported the patch of the mysql-5.6 code line that fixed several defects in the greedy optimization:

      1. The greedy optimizer calculated the 'compare-cost' (CPU-cost) for iterating over the partial plan result at each level in the query plan as 'record_count / (double) TIME_FOR_COMPARE'

This cost was only used locally for 'best' calculation at each level, and not accumulated into the total cost for the query plan.

This fix added the 'CPU-cost' of processing 'current_record_count' records at each level to 'current_read_time' before it is used as 'accumulated cost' argument to recursive best_extension_by_limited_search() calls. This ensured that the cost of a huge join-fanout early in the QEP was correctly reflected in the cost of the final QEP.

To get identical cost for a 'best' optimized query and a straight_join with the same join order, the same change was also applied to optimize_straight_join() and get_partial_join_cost() 1. Furthermore to get equal cost for 'best' optimized query and a straight_join the new code substrcated the same '0.001' in optimize_straight_join() as it had been already done in best_extension_by_limited_search() 1. When best_extension_by_limited_search() aggregated the 'best' plan a plan was 'best' by the check :

'if ((search_depth == 1) || (current_read_time < join->best_read))'

The term '(search_depth == 1' incorrectly caused a new best plan to be collected whenever the specified 'search_depth' was reached - even if this partial query plan was more expensive than what we had already found.

circle-info

Be notified of new MariaDB Server releases automatically by subscribingarrow-up-right to the MariaDB Foundation community announce 'at' lists.mariadb.org announcement list (this is a low traffic, announce-only list). MariaDB plc customers will be notified for all new releases, security issues and critical bug fixes for all MariaDB plc products thanks to the Notification Services.

MariaDB may already be included in your favorite OS distribution. More information can be found on the Distributions which Include MariaDB page.

This page is licensed: CC BY-SA / Gnu FDL

spinner

Last updated

Was this helpful?