The Ultimate Guide to High Availability with MariaDB

MariaDB 5.3.0 Changelog

You are viewing an old version of this article. View the current version here.

MariaDB 5.3.0 Changelog — page: 1 2 3 4 5 6

  • Revision #3112 [merge] Fri 2011-07-15 09:17:22 +0300 Automatic merge.
    • Revision #3106.1.3 Fri 2011-07-15 00:23:57 +0300 MWL#68 efficient partial matching
      • Added an initial set of feature-specific test cases
      • Handled the special case where the materialized subquery of an IN predicates consists of only NULL values.
      • Fixed a bug where making Item_in_subselect a constant, didn't respect its null_value value.
    • Revision #3106.1.2 Thu 2011-07-14 12:53:00 +0300 Fix Bug #777691
      • Analysis:
      • For some of the re-executions of the correlated subquery the where clause is false. In these cases the execution of the subquery detects that it must generate a NULL row because of implicit grouping. In this case the subquery execution reaches the following code in do_select():
      • while ((table= li++)) mark_as_null_row(table->table);
      • This code marks all rows in the table as complete NULL rows. In the example, when evaluating the field t2.f10 for the second row, all bits of Field::null_ptr[0] are set by the previous call to mark_as_null_row(). Then the call to Field::is_null() returns true, resulting in a NULL for the MAX function.
      • Thus the lines above are not suitable for subquery re-execution because mark_as_null_row() changes the NULL bits of each table field, and there is no logic to restore these fields.
      • Solution:
      • The call to mark_as_null_row() was added by the fix for bug Bug #613029. Therefore removing the fix for Bug #613029 corrects this wrong result. At the same time the test for Bug #613029 behaves correctly because the changes of MWL#89 result in a different execution path where:
        • the constant subquery is evaluated via JOIN::exec_const_cond
        • detecting that it has an empty result triggers the branch
        • if (zero_result_cause) return_zero_rows()
        • return_zero_rows() calls mark_as_null_row().
    • Revision #3106.1.1 [merge] Thu 2011-07-14 10:22:18 +0300 Automatic merge.
      • Revision #3102.2.2 Thu 2011-07-14 00:15:07 +0300 Fix Bug #809266
        • Analysis:
        • This is a bug in MWL#68, where it was incorrectly assumed that if there is a match in the only non-null key, then if there is a covering NULL row on all remaining NULL-able columns there is a partial match. However, this is not the case, because even if there is such a null-only sub-row, it is not guaranteed to be part of the matched sub-row. The matched sub-row and the NULL-only sub-row may be parts of different rows.
        • In fact there are two cases:
          • there is a complete row with only NULL values, and
          • all nullable columns contain only NULL values.
        • These two cases were incorrectly mixed up in the class member subselect_partial_match_engine::covering_null_row_width.
        • Solution:
        • The solution is to:
          • split covering_null_row_width into two members: has_covering_null_row, and has_covering_null_columns, and
            • take into account each state during initialization and execution.
      • Revision #3102.2.1 [merge] Wed 2011-07-13 17:11:46 +0300 Merged the fix for bug Bug #608744
        • Revision #3091.1.1 Wed 2011-07-13 17:09:09 +0300 Fixed bug Bug #809245
          • In addition to the bug fix explained below, the patch performs few renames, and adds some comments to avoid similar problems.
          • Analysis:
          • The failed assert was due to a bug in MWL#68, where it was incorrectly assumed that the size of the bitmap subselect_rowid_merge_engine::null_only_columns should be the same as the size of the array of Ordered_keys.
          • The bitmap null_only_columns contains bits to mark columns that contain only NULLs. Therefore the indexes of the bits to be set in null_only_columns are different from the indexes of the Ordered_keys. If there is a NULL-only column that appears in a table after the last partial match column with Ordered_key, this NULL-only column would require setting a bit with index bigger than the size of the bitmap null_only_columns.
          • Accessing such a bit caused the failed assert.
          • Solution:
          • Upon analysis, it turns out that null_only_columns is not needed at all, because we are looking for partial matches, and having such columns guarantees that there is a partial match for any corresponding outer value.
          • Therefore the patch removes subselect_rowid_merge_engine::null_only_columns.
  • Revision #3111 Thu 2011-07-14 22:24:59 -0700 Changed the default setting of the optimizer switch 'optimize_join_buffer_size'. Made it 'off' by default.
  • Revision #3110 Fri 2011-07-15 03:34:00 +0400 Test result update forgotten in pre-previous cset.
  • Revision #3109 Fri 2011-07-15 03:29:38 +0400 Valgrind fix for the previous cset:
    • {ha_myisam,ha_maria}::index_read_idx_map should also initialize end_range, because index condition function will attempt to check it. We initialize it like index_init() does.
  • Revision #3108 [merge] Thu 2011-07-14 20:06:46 +0400 Merge
    • Revision #3102.1.1 Thu 2011-07-14 01:53:05 +0400 Disable LooseScan and FirstMatch when outer joins are present.
  • Revision #3107 Thu 2011-07-14 17:44:37 +0400 Bug #778434 Wrong result with in_to_exists=on in maria-5.3-mwl89
    • Make {ha_myisam,ha_maria}::index_read_idx_map check pushed index condition.
    • Address review feedback (added comments)
  • Revision #3106 [merge] Wed 2011-07-13 22:19:32 -0700 Merge.
    • Revision #3104.1.1 Wed 2011-07-13 21:06:28 -0700
      • Fixed Bug #809179.
      • The attribute not_null_tables could be calculated incorrectly in the function SELECT_LEX::update_used_tables for queries over views with row items in the WHERE clause. It happened because no implementation of the virtual callback function eval_not_null_tables was provided for the class Item_row.
      • Also slightly optimized the code calculating the value of the maybe_null flag for tables in the function SELECT_LEX::update_used_tables.
  • Revision #3105 Wed 2011-07-13 20:00:28 -0700 Corrected the patch for Bug #809206 to fix valgrind failures.
  • Revision #3104 [merge] Wed 2011-07-13 12:14:35 -0700 Merge.
    • Revision #3101.1.1 Tue 2011-07-12 23:47:35 -0700
      • Fixed Bug #809206.
      • The bitmap of used tables must be evaluated for the select list of every materialized derived table / view and saved in a dedicated field.
      • This is also applied to materialized subqueries.
  • Revision #3103 Wed 2011-07-13 11:05:33 -0700
    • Corrected the code of the recent patch that had changed the base class for Item_func_xor. Added the implementation of the subst_argument_checker virtual method that the objects of this class used to use before the patch.
    • Reverted the previous result changes in sunselect_sj and subselect_sj_jcl6.
  • Revision #3102 Wed 2011-07-13 16:49:52 +0400
    • Update test results for previous cset
  • Revision #3101 [merge] Tue 2011-07-12 13:02:19 +0400
    • Merge
    • Revision #3095.1.2 Mon 2011-07-11 23:48:35 +0400
      • Port of code for: (part of testcase is in mysql-test/t/subquery*.test and will be ported separately)
        • Bug #11766642: crash in Item_field::register_field_in_read_map with view
        • (Former MySQL Bug #59793)
        • Prior to the refactoring in this patch, Item_cond_xor behaved partially as an Item_cond and partially as an Item_func. The reasoning behind this was that XOR is currently not optimized (thus should be Item_func instead of Item_cond), but it was planned optimize it in the future (thus, made Item_cond anyway to ease optimization later).
        • Even though Item_cond inherits from Item_func, there are differences between these two. One difference is that the arguments are stored differently. Item_cond stores them in a list while Item_func store them in an args[].
        • MySQL Bug #45221 was caused by Item_cond_xor storing arguments in the list while users of the objects would look for them in args[]. The fix back then was to store the arguments in both locations.
        • In this bug, Item_cond_xor initially gets two Item_field arguments. These are stored in the list inherited from Item_cond and in args[] inherited from Item_func. During resolution, find_field_in_view() replaces the Item_fields stored in the list with Item_direct_view_refs, but args[] still points to the unresolved Item_fields. This shows that the fix for 45221 was incorrect.
        • The refactoring performed in this patch removes the confusion by making the XOR item an Item_func period. A neg_transformer() is also implemented for Item_func_xor to improve performance when negating XOR expressions. An XOR is negated by negating one of the operands.
    • Revision #3095.1.1 Mon 2011-07-11 17:13:16 +0400
      • Alternate version of MySQL's fix for MySQL Bug #49453.
      • The cause of the crash is sj_nest->sj_subq_pred->unit->first_select()->item_list contains "stale" items for the second execution. By "stale" I mean that they have item->fixed==FALSE, and they are Item_field object instead of Item_direct_view_ref.
      • The solution is to use sj_nest->sj_subq_pred->unit->first_select()->ref_pointer_array. Surprisingly, that array contains items that are ok.
      • Oracle team has introduced and is using NESTED_JOIN::sj_inner_exprs, but we go without that and always copy the ref_pointer_array.
  • Revision #3100 Mon 2011-07-11 10:56:48 -0700
    • Fixed Bug #793386. Auto-generated names for view field items must be allocated in the statement memory, not in the execution memory of the statement.
  • Revision #3099 Sun 2011-07-10 17:19:45 -0700
    • Fixed Bug #806504. Missing initialization of the bitmap not_null_tables_cache to 0 in the function Item_func::eval_not_null_tables caused this bug. This function is called indirectly from the function SELECT_LEX::update_used_tables after merging mergeable views and derived tables into the main query. The leaf tables of resulting query may change their bitmap numbers after this merge. That's why the not_null_tables_cache bitmaps must be updated. Due to the bug mentioned above the result of the re-evaluation of the not_null_tables_cache turned out to be incorrect in some cases. This could trigger an invalid conversion of outer joins into inner joins leading to invalid query result sets.
    • Also removed an implicit conversion from int to bool in the function SELECT_LEX::update_used_tables.
  • Revision #3098 [merge] Sun 2011-07-10 13:41:30 +0200
    • merge
  • Revision #3097 [merge] Sun 2011-07-10 13:01:00 +0200
    • merge
  • Revision #3096 Sat 2011-07-09 22:34:56 -0700
    • Fixed Bug #806097. The value of THD::used tables should be re-evaluated after merges of views and derived tables into the main query. Now it's done in the function SELECT_LEX::update_used_tables. The re-evaluation of the 'used_table' bitmaps for the items in HAVING, GROUP BY and ORDER BY clauses has been added as well.
  • Revision #3095 Sat 2011-07-09 16:33:40 +0400
    • Semi-join fixes: make COST_VECT objects survive add_io(add_io_cnt=0, add_avg_cost=...) calls without getting NaN in internal fields.
  • Revision #3094 Sat 2011-07-09 13:47:41 +0400
    • [No BUG#] Fixes for problems discovered when running mysql-trunk's subquery testsuite
  • Revision #3093 [merge] Sat 2011-07-09 11:20:15 +0400
    • Merge @@optimizer_switch default settings changes into 5.3
    • Revision #3089.2.4 Fri 2011-07-08 22:01:02 +0400
      • Update test results for previous csets.
    • Revision #3089.2.3 Fri 2011-07-08 19:09:30 +0400
      • Make table_elimination=on|off flag to be always present in @@optimizer_switch.
    • Revision #3089.2.2 Fri 2011-07-08 18:49:53 +0400
      • Forgot to add these two files when setting semijoin=off by default: - Scavenged subquery tests from testcases other than t/subselect*.test and put them into single file
    • Revision #3089.2.1 Fri 2011-07-08 18:46:47 +0400
      • Set the default to be mrr=off,mrr_sort_keys=off:
        • Set the default
        • Adjust the testcases so that 'new' tests are run with optimizations turned on.
        • Pull out relevant tests from "irrelevant" tests and run them with optimizations on.
        • Run range.test and innodb.test with both mrr=on and mrr=off
  • Revision #3092 [merge] Fri 2011-07-08 16:42:59 -0700
    • Merge.
    • Revision #3090.1.1 Fri 2011-07-08 16:39:28 -0700
      • Fixed Bug #806510. The bug was caused by an incorrect code of the function Item_direct_view_ref::replace_equal_field introduced in the patch for bugs 717577, 724942. The function erroneously returned the wrapped field instead of the Item_direct_view_ref object itself in the cases when no replacement happened.
      • The bug masked two other minor bugs that could result in not quite correct output of the EXPLAIN command for some queries. They were fixed in the patch as well.
  • Revision #3091 [merge] Fri 2011-07-08 10:56:46 +0300
  • Revision #3090 [merge] Thu 2011-07-07 13:06:40 -0700
    • Merge.
    • Revision #3088.1.1 Thu 2011-07-07 13:04:48 -0700
      • Fixed Bug #806477. The offending query returns a wrong result set because the optimizer erroneously eliminated the where condition evaluated it to TRUE. The cause of this wrong transformation was that the flag maybe_null for an inner table of the outer join was not set to TRUE after the table had replaced the wrapping view. Now the function SELECT_LEX::update_used_tables resets the value of the maybe_null flag for each leaf table of the query after all merges of views have been done.
  • Revision #3089 Thu 2011-07-07 16:28:26 +0300
    • Fix Bug #806943
      • Analysis: This bug is yet another incarnation of the generic problem where optimization of the outer query triggers evaluation of a subquery, and this evaluation performs a destructive change to the subquery plan. Specifically a temp table is created for the DISTINCT operation that replaces the original subquery table. Later, select_describe() attempts to print the table name, however, there is no corresponding TABLE_LIST object to the internal temp table, so we get a crash. Execution works fine because it is not interested in the corresponding TABLE_LIST object (or its name).
      • Solution: Similar to other such bugs, block the evaluation of expensive Items in convert_const_to_int().
  • Revision #3088 [merge] Wed 2011-07-06 17:26:01 -0700
    • Merge.
    • Revision #3086.1.1 Wed 2011-07-06 17:24:42 -0700
      • Fixed Bug #806431. The function generate_derived_keys_for_table incorrectly handled the cases when a materialized view or derived table could be accessed by different keys on the same fields if these keys depended on the same tables.
  • Revision #3087 Wed 2011-07-06 21:32:07 +0300
  • Revision #3086 [merge] Wed 2011-07-06 17:27:38 +0300
    • Merge the fix for Bug #802979
    • Revision #3070.1.1 Mon 2011-07-04 14:51:16 +0300
      • Fix Bug #802979
      • Analysis: This bug consists of two related problems that are result of too early evaluation of single-row subqueries during the optimization phase of the outer query.
        • Several optimizer code paths try to evaluate single-row subqueries in order to produce a constant and use that constant for further optimzation.
        • When the execution of the subquery peforms destructive changes to the representation of the subquery, and these changes are not anticipated by the subsequent optimization phases of the outer query, we tipically get a crash or failed assert.
        • Specifically, in this bug the inner-most suqbuery with DISTINCT triggers a substitution of the original JOIN object by a single-table JOIN object with a temp table needed to perform the DISTINCT operation (created by JOIN::make_simple_join).
        • This substitution breaks EXPLAIN because: a) in the first example JOIN::cleanup no longer can reach the original table of the innermost subquery, and close all indexes, and b) in this second test query, EXPLAIN attempts to print the name of the internal temp table, and crashes because the temp table has no name (NULL pointer instead).
      • Solution:
        • a) fully disable subquery evaluation during optimization in all cases - both for constant propagation and range optimization, and
        • b) change JOIN::join_free() to perform cleanup irrespective of EXPLAIN or not.
  • Revision #3085 [merge] Wed 2011-07-06 10:30:51 +0400
    • Merge fix for Bug #611704
    • Revision #3082.1.1 Wed 2011-07-06 10:21:31 +0400
      • Bug #611704: Crash in replace_where_subcondition with nested subquery and semijoin=on
      • SELECT_LEX::merge_subquery should not set "(*in_subq)->emb_on_expr_nest= derived" for subqueries that are in the ON expressions of semi-joins.
  • Revision #3084 Tue 2011-07-05 22:38:38 +0200
    • fix compile warnings
  • Revision #3083 [merge] Tue 2011-07-05 21:46:53 +0200
    • merge Windows performance patches into 5.3
    • Revision #2732.40.14 Sun 2011-06-26 01:07:39 +0200
      • set errno to EBADF, if file descriptor < 0 in my_write()
    • Revision #2732.40.13 Sun 2011-06-19 17:19:22 +0200
      • Fix "make dist" : add my_winfile.c and my_winerr.c to EXTRA_DIST list
    • Revision #2732.40.12 Sun 2011-06-19 00:51:41 +0200
      • add missing DBUG_RETURN
    • Revision #2732.40.11 Sun 2011-06-19 00:29:49 +0200
      • fix compile error on *nix
    • Revision #2732.40.10 Sat 2011-06-18 21:56:47 +0200
      • dummy change to trigger the buildbot
    • Revision #2732.40.9 Fri 2011-06-17 00:29:22 +0200
      • Point to the correct documentation on building in our KB.
    • Revision #2732.40.8 Thu 2011-06-16 14:51:50 +0200
      • Fix MySQL Bug #21978 : 'flush_time' value set for 1800 sec
      • This setting is obsolete now. It could makes sense in the past, situations open file handles limit was low. It does not make sense anymore to flush all files every 1.5 hours now, after 2048 myisam file limit is removed as fix to MySQL Bug #24509.
    • Revision #2732.40.7 Thu 2011-06-16 14:33:09 +0200
      • Accept innodb_flush_method values previously allowed on Unix only map them to corresponding Windows CreateFile flags, O_DSYNC=>FILE_FLAG_WRITE_THROUGH ALL_O_DIRECT=>FILE_FLAG_NO_BUFFERING
      • Ability to specify innodb_flush_method=O_DSYNC fixes MySQL Bug #31876 (InnoDB commit performance slow on Windows XP), by removing an extra FlushFileBuffers() call overhead.
    • Revision #2732.40.6 Mon 2011-06-13 02:38:16 +0200
      • fix warnings
    • Revision #2732.40.5 Sun 2011-06-12 16:44:41 +0200
      • fix mismerge
    • Revision #2732.40.4 [merge] Sun 2011-06-12 16:26:43 +0200
      • merge
    • Revision #2732.40.3 [merge] Sun 2011-06-12 16:24:00 +0200
      • merge
        • Revision #2732.42.1 Sun 2011-06-12 16:07:18 +0200
          • Fix XtraDB Bug #714143 : Windows native async io is disabled.
          • The patch uses completion ports for asynchronous IO notification , instead of formerly used notification via event . This also removes the limit of 64 async IOs per background IO thread (this limit was forced by using WaitForMultipleObjects in previous AIO implementation)
    • Revision #2732.40.2 [merge] Sun 2011-06-12 16:11:05 +0200
    • Revision #2732.40.1 [merge] Sun 2011-06-12 16:10:38 +0200
      • merge
        • Revision #2732.39.1 Sun 2011-06-12 15:52:07 +0200
          • Backport Fix for MySQL Bug #24509 - 2048 file descriptor limit on windows needs increasing.
          • The patch replaces the use of the POSIX I/O interfaces in mysys on Windows with the Win32 API calls (CreateFile, WriteFile, etc). The Windows HANDLE for the open file is stored in the my_file_info struct, along with a flag for append mode (because the Windows API does not support opening files in append mode in all cases) The default max open files has been increased to 16384 and can be increased further by setting --max-open-files=<value> during the server start.
          • Noteworthy benefit of this patch is that it removes limits from the table_cache size - allowing for more simultaneus users
  • Revision #3082 [merge] Tue 2011-07-05 21:48:50 +0400
    • Merge fix for Bug #803365
    • Revision #3073.1.1 Tue 2011-07-05 21:22:13 +0400
      • Bug #803365: Crash in pull_out_semijoin_tables with outer join + semijoin + derived tables in maria-5.3 with WL#106
      • Don't perform table pullout out of semi-join nests that have nested outer joins.
  • Revision #3081 Tue 2011-07-05 15:28:15 +0200
    • MWL#163 Bug #798213: Remove the --innodb-release-locks-early feature.
    • The Bug #798213 exposes a design flaw in --innodb-release-locks-early. It does not work with InnoDB crash recovery, so it breaks transactional integrety. So remove the feature.
  • Revision #3080 Tue 2011-07-05 10:32:49 +0400
    • Update test results for the previous cset.
  • Revision #3079 Tue 2011-07-05 01:44:15 +0400
    • Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off
    • Adjust the testcases:
      • Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled)
      • Let all other test files run with the new default settings (i.e. with new optimizations disabled)
      • Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.
  • Revision #3078 [merge] Mon 2011-07-04 11:02:35 -0700
    • Merge.
    • Revision #3076.1.1 Sun 2011-07-03 14:59:01 -0700
      • Fixed Bug #804686. The assert conditions in the functions Item_direct_ref_to_ident::transform and Item_direct_ref_to_ident::compile could be not valid after constant propagation when fields and field references may be substituted for constants. Not only these invalid asserts have been removed, but the functions containing them have been removed as well because now Item_ref::transform and Item_ref::compile can be used instead of them.
  • Revision #3077 [merge] Mon 2011-07-04 17:27:46 +0300
    • Automatic merge
  • Revision #3076 Sat 2011-07-02 17:37:59 +0300
    • Fixed compilation & test issues found by buildbot
  • Revision #3075 Fri 2011-07-01 21:53:47 -0700
    • Fixed Bug #804515. If no index is used to access a materialized derived table or view then the value of TABLE_REF::key for this table must be (-1).
  • Revision #3074 [merge] Fri 2011-07-01 15:35:34 +0300
    • Automatic merge
    • Revision #3066.1.5 [merge] Fri 2011-07-01 15:16:10 +0300 Merge with 5.2
    • Revision #3066.1.4 Fri 2011-07-01 15:08:30 +0300
      • Added progress reporting for alter table, LOAD DATA INFILE and for aria tables: check table, repair table, analyze table.
        • The client gets a progress report message that triggers a callback function if requested with mysql_options(MYSQL_PROGRESS_CALLBACK, function)
        • Added Progress field last to 'show processlist'
        • Stage, Max_stage and Progress field added to information_schema.progresslist
        • The 'mysql' client by defaults enables progress reports when the output is a tty.
        • Added progress_report_time time variable to configure how often progress reports is sent to client
      • Added read only system variable 'in_transaction' which is 1 if we have executed a BEGIN statement.
    • Revision #3066.1.3 Fri 2011-07-01 14:16:36 +0300
      • Updated result
    • Revision #3066.1.2 Fri 2011-07-01 10:20:11 +0200
      • Added read only system variable 'in_transaction' which tells if there's an active transaction.
      • fixed a bug - not clearing "in transaction" status on set @@autocommit=1
    • Revision #3066.1.1 Fri 2011-07-01 09:05:15 +0200
      • Removed check_license() function
  • Revision #3073 Fri 2011-07-01 13:22:23 +0400
    • Buildbot run fixes:
      • update suite/pbxt/r/status.result with changes that arise from addition of Handler_tmp_% status variables.
  • Revision #3072 [merge] Fri 2011-07-01 12:45:45 +0400
    • Merge first chunk of OJ+SJ fixes into 5.3
    • Revision #3068.1.3 Thu 2011-06-30 20:49:11 +0400
      • Fix buildbot failures:
        • JOIN::prepare would have set JOIN::table_count to incorrect value (bad merge of MWL 106)
        • optimize_keyuse() would use table-bit as table number (the change in optimize_keyuse is also the reason for query plan changes. Not expected to have much effect because only handles cases of no index statistics)
        • st_select_lex::register_dependency_item() ignored the fact that some of the selects on the dependency paths could have been merged to their parents (because they were mergeable VIEWs)
        • Undo the incorrect fix in Item_subselect::recalc_used_tables(): do not call fix_after_pullout() for Item_subselect::Ref_to_outside members.
    • Revision #3068.1.2 Wed 2011-06-29 15:07:28 +0400
      • Bug #802965: Crash in do_copy_not_null with semijoin=on in maria-5.3
        • The crash was because a NOT NULL table column inside the subquery was considered NULLable because the code thought it was on the inner side of an outer join nest.
        • Fixed by making correct distinction between tables inside outer join nests and inside semi-join nests.
    • Revision #3068.1.1 [merge] Wed 2011-06-29 11:52:26 +0400
      • Merge
        • Revision #3062.3.4 Tue 2011-06-28 18:25:02 +0400
          • Remove garbage comment
        • Revision #3062.3.3 Tue 2011-06-28 17:42:10 +0400
          • Followup to previous commit:
            • Update test results
            • Fix a problem with PS:
              • convert_subq_to_sj() should not save where to prep_where or on_expr to prep_on_expr.
              • After an unmerged subquery predicate has been pulled, it should call fix_after_pullout() for outer_refs.
        • Revision #3062.3.2 Tue 2011-06-28 00:51:26 +0400
          • Test: enable semi-join processing for cases of semi-joins and outer joins, except for the case when the subquery is in the ON clause.
        • Revision #3062.3.1 [merge] Mon 2011-06-27 23:40:58 +0400
          • Merge semi-join+outer-join fixes into 5.3
  • Revision #3071 Thu 2011-06-30 19:32:19 -0700
    • Fixed Bug #803851. The function generate_derived_keys_for_table should set the value of the number of keys for the derived table to 0 before it starts generating key definitions for the table. It's important as the function can be called twice by the optimizer for a derived table if the query contains a subquery to which the IN-EXIST transformation is applicable.
    • Fixed a valgrind complain.
  • Revision #3070 Wed 2011-06-29 20:07:24 -0700
    • Fixed Bug #802845. If the expression for a derived table contained a clause LIMIT 0 SELECT from such derived table incorrectly returned a non-empty set.
    • Fixed by ensuring JOIN::do_send_rows to be updated after the call of st_select_lex_unit::set_limit that sets the value of JOIN::unit->select_limit_cnt.

MariaDB 5.3.0 Changelog — page: 1 2 3 4 5 6

Comments

Comments loading...
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.