circle-info
Live Webinar | From Strategy to Execution: Your Practical MySQL to MariaDB Migration Plan
Register Nowarrow-up-right
search
Download MariaDBContact Us

MariaDB 5.3.3 Changelog

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

Release date: 21 Dec 2011

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.

hashtag
constant expression"

  • Revision #3327.1.1arrow-up-right Sat 2011-12-03 23:06:16 +0200

    • Added handler and temporary table usage to mytop

    • Fixed prompt on reconnect in mysql client

  • Revision #3339arrow-up-right Fri 2011-12-09 14:30:50 -0800

    • Fixed Bug #901312arrow-up-right

    • The function setup_sj_materialization_part1() forgot to set the value of TABLE::map for any materialized IN subquery.

    • This could lead to wrong results for queries with subqueries that were converted to queries with semijoins.

  • Revision #3338arrow-up-right Thu 2011-12-08 16:29:45 +0400

    • Bug #901655arrow-up-right ST_BUFFER asserts with a coplicated shape.

    • Coinciding nodes can appear as a result of DOUBLE inaccuracy.

    • We should test that before we start the loop.

    • Also the spatial relations can be calculated faster if we check MBR relations first. And we do have the shape's MBR-s now.

    • per-file comments:

      • sql/gcalc_slicescan.cc

      • sql/gcalc_slicescan.h

      • sql/gcalc_tools.cc

      • sql/item_geofunc.cc

        • Bug #901655arrow-up-right ST_BUFFER asserts with a coplicated shape.

        • MBR for the shapes calculated, and MBR checks added before we start the heavy calculations.

      • sql/spatial.h

  • Revision #3337arrow-up-right Thu 2011-12-08 04:22:38 +0400

    • Small semi-join optimization improvement:

      • if we're considering FirstMatch access with one inner table, and @@optimizer_switch has semijoin_with_cache flag, calculate costs as if we used join cache (because we will be able to do so)

  • Revision #3336arrow-up-right [merge] Thu 2011-12-08 02:47:54 +0400

  • Revision #3335arrow-up-right Thu 2011-12-08 02:12:48 +0400

    • Bug #901032arrow-up-right: Wrong result for MIN/MAX on an indexed column with materialization and semijoin

      • opt_sum_query() should not assume that join tables from sj-materialization have known numbers of rows.

  • Revision #3334arrow-up-right Tue 2011-12-06 13:42:18 -0800

    • Fixed Bug #900469arrow-up-right.

    • The execution plan cannot use sorting on the first table from the sequence of the joined tables if it plans to employ the block-based hash join algorithm.

  • Revision #3333arrow-up-right Tue 2011-12-06 02:46:42 -0800

    • Fixed Bug #899509arrow-up-right.

    • The optimizer must ignore any possible hash join key when looking for the query execution plan with join_cache_level set to 0.

  • Revision #3332arrow-up-right [merge] Mon 2011-12-05 18:52:50 -0800

    • Merge

    • Revision #3330.1.1arrow-up-right [merge] Mon 2011-12-05 18:51:56 -0800

      • Merge

      • Revision #3328.1.1arrow-up-right Mon 2011-12-05 09:50:24 -0800

        • Fixed Bug #899777arrow-up-right.

        • KEYUSE elements for a possible hash join key are not sorted by field numbers of the second table T of the hash join operation. Besides some of these KEYUSE elements cannot be used to build any key as their key expressions depend on the tables that are planned to be accessed after the table T.

        • The code before the patch did not take this into account and, as a result, execition of a query the employing block-based hash join algorithm could cause a crash or return a wrong result set.

  • Revision #3331arrow-up-right Tue 2011-12-06 01:04:27 +0400

    • Bug #899962arrow-up-right: materialized subquery with join_cache_level=3

    • Make create_tmp_table() set KEY_PART_INFO attributes for the keys it creates.

    • This wasn't needed before but is needed now, when temp. tables that are results of SJ-Materialization are being used for joins.

    • This particular bug depended on HA_VAR_LENGTH_PART being set, but also added code to set HA_BLOB_PART and HA_NULL_PART when appropriate.

  • Revision #3330arrow-up-right Mon 2011-12-05 10:24:14 +0400

    • Update test result missed in the previous cset

  • Revision #3329arrow-up-right Mon 2011-12-05 01:31:42 +0400

    • Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED.

    • Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.

  • Revision #3328arrow-up-right Sun 2011-12-04 07:43:33 -0800

    • Fixed Bug #899696arrow-up-right.

    • If has been decided that the first match strategy is to be used to join table T from a semi-join nest while no buffer can be employed to join this table then no join buffer can be used to join any table in the join sequence between the first one belonging to the semi-join nest and table T.

  • Revision #3327arrow-up-right Fri 2011-12-02 00:36:55 +0200

    • Added new file (for netware)

    • Added some file to ignore

  • Revision #3326arrow-up-right Fri 2011-12-02 00:34:59 +0200

    • Fixes for netware by Guenter Knauf

  • Revision #3325arrow-up-right Fri 2011-12-02 00:24:58 +0200

    • Patch to get MariaDB to compile on CYGWIN; By Guenter Knauf

    • Increased number of locks in thr_lock (used only when testing)

  • Revision #3324arrow-up-right Wed 2011-11-30 10:22:53 -0800

    • Fixed Bug #898073arrow-up-right.

    • The tables from the same semi-join or outer join nest cannot use join buffers if in the join sequence of the query execution plan they are separated by a table that is planned to be joined without usage of a join buffer.

  • Revision #3323arrow-up-right [merge] Wed 2011-11-30 08:28:40 +0200

    • Merge the fix of Bug #825051arrow-up-right

    • Revision #3321.1.1arrow-up-right Tue 2011-11-29 23:06:39 +0200

      • Fixed Bug #825051arrow-up-right

      • The cause of the wrong result was that Item_ref_null_helper::get_date() didn't use a method of the *_result() family, and fetched the data for the field from the current row instead of result_field. Changed to use the correct *_result() method, like to all other similar methods of Item_ref_null_helper.

  • Revision #3322arrow-up-right Tue 2011-11-29 23:09:06 +0200

  • Revision #3321arrow-up-right Tue 2011-11-29 15:27:52 +0400

    • Bug #857066arrow-up-right Wrong result with ST_DISJOINT when using an index.

    • DISJOINT can't be properly optimized with the RTree keys in MyISAM also.

    • per-file comments:

      • storage/myisam/rt_index.c

  • Revision #3320arrow-up-right Tue 2011-11-29 02:11:13 +0400

    • Bug #857066arrow-up-right Wrong result with ST_DISJOINT when using an index the ST_DISJOINT can't be properly optimized with the RTree key at the moment.

    • per-file comments:

      • storage/maria/ma_rt_index.c

  • Revision #3319arrow-up-right Mon 2011-11-28 15:24:07 +0200

  • Revision #3318arrow-up-right Mon 2011-11-28 12:42:14 +0200

    • Fixed Bug #747278arrow-up-right

    • The problem was that when we have single row subquery with no rows Item_cache(es) which represent result row was not null and being requested via element_index() returned random value.

    • The fix is setting all Item_cache(es) in NULL before executing the query (reset() method) which guaranty NULL value of whole query or its elements requested in any way if no rows was found.

    • set_null() method was added to Item_cache to guaranty correct NULL value in case of reseting the cache.

  • Revision #3317arrow-up-right Sat 2011-11-26 14:23:00 -0800

    • Set new default values for the optimizer switch flags 'derived_merge' and 'derived_with_keys'. Now they are set on by default.

  • Revision #3316arrow-up-right [merge] Sat 2011-11-26 12:27:52 +0400

  • Make functions that operate on SJ_TMP_TABLE be member functions

  • Make Loose_scan_opt data members private

  • Revision #3314.1.4arrow-up-right Fri 2011-11-25 21:45:58 +0400

    • Update test results

  • Revision #3314.1.3arrow-up-right Fri 2011-11-25 15:48:56 +0400

    • Update test results

  • Revision #3314.1.2arrow-up-right Fri 2011-11-25 14:57:27 +0400

    • Remove garbage comments

  • Revision #3314.1.1arrow-up-right [merge] Fri 2011-11-25 14:28:43 +0400

    • Merge

    • Revision #3275.1.3arrow-up-right Fri 2011-11-25 05:56:58 +0400

      • Semi-join optimizations code cleanup part 2:

        • Make EXPLAIN display "Start temporary" at the start of the fanout (it used to display at the first table whose rowid gets into temp. table which is not that useful for the user)

        • Updated test results (all checked)

    • Revision #3275.1.2arrow-up-right Wed 2011-11-23 04:25:52 +0400

      • Semi-join optimizations code cleanup:

        • Break down POSITION/advance_sj_state() into four classes representing potential semi-join strategies.

        • Treat all strategies uniformly (before, DuplicateWeedout was special as it was the catch-all strategy. Now, we're still relying on it to be the catch-all, but are able to function,e.g. with firstmatch=on,duplicate_weedout=off.

        • Update test results (checked)

    • Revision #3275.1.1arrow-up-right Sat 2011-11-12 20:50:11 +0200

      • Bug #887468arrow-up-right: Second assertion `keypart_map' failed in maria_rkey with semijoin

      • in advance_sj_state: Do not try to construct LooseScan strategy if we're already behind the last LooseScan table.

  • Revision #3315arrow-up-right Fri 2011-11-25 22:54:13 +0400

    • Remove garbage comment

  • Revision #3314arrow-up-right Thu 2011-11-24 22:56:02 -0800

    • Currently innodb_plugin does not support ICP. Part2.

  • Revision #3313arrow-up-right Thu 2011-11-24 23:47:50 +0200

  • Revision #3312arrow-up-right Thu 2011-11-24 23:15:40 +0200

    • Fix Bug #894326arrow-up-right

    • The patch also fixes an unrelated compiler warning.

    • Analysis:

      • The temporary table created during SJ-materialization might be used for sorting for a group by operation. The sort buffers for this internal temporary table were not cleared by the execution code after each subquery re-execution. This resulted in a memory leak detected by valgrind.

    • Solution:

      • Cleanup the sort buffers for the semijon tables as well.

  • Revision #3311arrow-up-right Thu 2011-11-24 12:19:37 -0800 Currently innodb_plugin does not support ICP.

  • Revision #3310arrow-up-right Thu 2011-11-24 15:12:10 +0200

  • Revision #3309arrow-up-right Thu 2011-11-24 16:26:13 +0400

    • fixes to make compilers happy.

    • per-file comments:

      • mysql-test/t/gis-precise.test

        • number-to-string conversion differs on Windows.

        • Have to tolerate this while GIS data is stored in doubles.

      • sql/spatial.cc

        • prev_x initialization added.

  • Revision #3308arrow-up-right Wed 2011-11-23 23:13:51 +0200

    • Fix Bug #893486arrow-up-right

    • Analysis:

      • The bug is a result of an incomplete fix for Bug #869036arrow-up-right

      • That fix didn't take into account that there may be a case when ther are no NULLs in the materialized subquery, however all columns without NULLs may not be grouped in the only non-null index. This is the case when the left subquery expression has nullable columns.

    • Solution:

      • The patch handles two missing sub-cases of the case when there are no value (non-null matches) for any outer expression, and there are both NULLs and non-NUll values in the outer reference.

        1. If the materialized subquery contains no NULLs there cannot be a partial match, because there are no NULLs in those columns where the outer reference has no NULLs.

        2. If the materialized subquery contains NULLs, but there exists a column, such that its corresponding outer expression has no NULL, and this column also has no NULL. Then there cannot be a partial match either.

  • Revision #3307arrow-up-right Tue 2011-11-22 17:57:33 +0400

    • Small fixes to make compilers happy.

  • Revision #3306arrow-up-right Tue 2011-11-22 17:32:05 +0400

    • Windows has no 'nearbyint' in libraries.

    • So removed.

  • Revision #3305arrow-up-right [merge] Tue 2011-11-22 12:06:46 +0200

  • Revision #3304arrow-up-right Mon 2011-11-21 22:16:01 +0200

  • Revision #3303arrow-up-right Mon 2011-11-21 22:01:47 +0200

    • Fix Bug #833777arrow-up-right

    • Fix test to pass on 32-bit machines by reducing the depth of subquery nestedness to less than 31 (sizeof(ulong)-1).

  • Revision #3302arrow-up-right [merge] Mon 2011-11-21 11:21:30 -0800

    • Merge.

    • Revision #3300.1.1arrow-up-right Mon 2011-11-21 09:06:35 -0800

      • Fixed Bug #887496arrow-up-right

      • This bug in the function Loose_scan_opt::check_ref_access_part1 could lead to choosing an invalid execution plan employing a loose scan access to a semi-join table even in the cases when such access could not be used at all. This could result in wrong answers for some queries with IN subqueries.

  • Revision #3301arrow-up-right Mon 2011-11-21 18:00:55 +0200

    • Fix Bug #833777arrow-up-right

    • Analysis:

      • The optimizer distinguishes two kinds of 'constant' conditions: expensive ones, and non-expensive ones. The non-expensive conditions are evaluated inside make_join_select(), and if false, already the optimizer detects empty query results.

      • In order to avoid arbitrarily expensive optimization, the evaluation of expensive constant conditions is delayed until execution. These conditions are attached to JOIN::exec_const_cond and evaluated in the beginning of JOIN::exec. The relevant execution logic is:

  • As a result, when an expensive constant condition is TRUE, it is evaluated twice - once through JOIN::exec_const_cond, and once through JOIN::cond. When the expensive constant condition is a subquery, predicate, the subquery is evaluated twice. If we have many levels of subqueries, this logic results in a chain of recursive subquery executions that walk a perfect binary tree. The result is that for subquries with depth N, JOIN::exec is executed O(2^N) times.

  • Solution:

    • Notice that the second execution of the constant conditions happens inside do_select(), in the branch: if (join->table_count == join->const_tables) { ... } In this case exec_const_cond is equivalent to the whole WHERE clause, therefore the WHERE clause has already been checked in the beginnig of JOIN::exec, and has been found to be true. The bug is addressed by not evaluating the WHERE clause if there was exec_const_conds, and it was TRUE.

  • Revision #3300arrow-up-right Mon 2011-11-21 07:00:14 -0800

    • Corrected the patch that made the optimizer switch for index condition pushdown set to 'on' by default.

  • Revision #3299arrow-up-right Mon 2011-11-21 05:16:16 -0800

    • Made the optimizer switch for index condition pushdown set to 'on' by default.

  • Revision #3298arrow-up-right Sun 2011-11-20 04:53:07 -0800

    • Fixed Bug #892725arrow-up-right.

    • A non-first execution of a prepared statement missed a call of the TABLE_LIST::process_index_hints() method in the code of the function setup_tables().

    • At some scenarios this could lead to the choice of a quite inefficient execution plan for the base query of the prepared statement.

  • Revision #3297arrow-up-right Sun 2011-11-20 12:30:43 +0400

  • Revision #3296arrow-up-right Fri 2011-11-18 13:32:21 -0800

    • Fixed Bug #891995arrow-up-right

    • This bug in the function setup_semijoin_dups_elimination() could lead to invalid choice of the sequence of tables for which semi-join duplicate elimination was applied.

  • Revision #3295arrow-up-right Fri 2011-11-18 09:35:51 -0800

    • Fixed Bug #891953arrow-up-right

    • Due to this bug the function SEL_IMERGE::or_sel_tree_with_checks() could build an inconsistent merge tree if one of the SEL_TREEs in the resulting index merge happened to contain a full key range.

    • This could trigger an assertion failure.

  • Revision #3294arrow-up-right Fri 2011-11-18 18:15:06 +0400

    • unused variable removed.

  • Revision #3293arrow-up-right Fri 2011-11-18 17:56:42 +0400

    • GCALC_CHECK_WITH_FLOAT disabled.

    • That's not a good option for an onrdinary user.

  • Revision #3292arrow-up-right Fri 2011-11-18 04:41:25 -0800

    • Fixed Bug #800184arrow-up-right

    • The function key_and() erroneously called SEL_ARG::increment_use_count() when SEL_ARG::incr_refs() should had been called. This could lead to wrong values of use_count for some SEL_ARG trees.

  • Revision #3291arrow-up-right [merge] Thu 2011-11-17 08:00:22 -0800

  • Revision #3290arrow-up-right Thu 2011-11-17 18:03:47 +0400

    • small fixes to make compiler happy.

  • Revision #3289arrow-up-right Thu 2011-11-17 17:12:58 +0400

    • test results updated.

  • Revision #3288arrow-up-right [merge] Thu 2011-11-17 14:27:00 +0400

    • merging.

    • Revision #2978.3.42arrow-up-right [merge] Sat 2011-11-12 19:56:29 +0400

      • merging.

    • Revision #2978.3.41arrow-up-right Sun 2011-10-16 21:16:53 +0500

      • code cleanup.

    • Revision #2978.3.40arrow-up-right Sun 2011-10-16 19:55:37 +0500

      • GIS code cleanup.

    • Revision #2978.3.39arrow-up-right Fri 2011-10-14 18:37:40 +0500

      • #define added

    • Revision #2978.3.38arrow-up-right Fri 2011-10-14 17:57:07 +0500

      • repeating calcualtions eliminated.

    • Revision #2978.3.37arrow-up-right Fri 2011-10-14 16:10:55 +0500

      • GIS code.

      • Forward calculations introduced.

      • per-file comments:

        • sql/gcalc_slicescan.cc

        • sql/gcalc_slicescan.h

        • sql/gcalc_tools.cc

        • sql/gcalc_tools.h

        • sql/item_geofunc.cc

    • Revision #2978.3.36arrow-up-right Thu 2011-10-06 17:41:28 +0500

      • Copyright notices fixed.

    • Revision #2978.3.35arrow-up-right Wed 2011-10-05 14:45:39 +0500

      • Valgrind warning fixed.

      • Coordinate size limitation removed.

      • per-file comments:

        • mysql-test/r/gis-precise.result

          • test result updated.

        • sql/gcalc_slicescan.cc

          • Check coordinate extent to pick better precidion in the ::set_double()

        • sql/gcalc_slicescan.h

          • free_list() can lead to valgrind warnig. Fixed

        • sql/gcalc_tools.cc

          • free_list() call changed.

    • Revision #2978.3.34arrow-up-right Tue 2011-10-04 15:29:39 +0500

      • GIS code cleanup.

      • GCALC_xxx macros fixed for the GCALC_DBUG_OFF case.

      • per-file comments:

        • sql/gcalc_slicescan.h

          • GIS code cleanup.

    • Revision #2978.3.33arrow-up-right Tue 2011-10-04 15:01:21 +0500

      • GIS library code cleanup.

      • GCALC_DBUG_OFF and related infrastructure defined so we can enable/disable debugging conveniently.

      • per-file comments:

        • sql/gcalc_slicescan.cc

          • GIS library code cleanup.

        • sql/gcalc_slicescan.h

          • GIS library code cleanup.

        • sql/gcalc_tools.cc

          • GIS library code cleanup.

        • sql/gcalc_tools.h

          • GIS library code cleanup.

    • Revision #2978.3.32arrow-up-right Fri 2011-09-23 17:00:36 +0500

      • Bug #857087arrow-up-right Wrong result with ST_INTERSECTS and LINESTRINGs

      • Line autointersection point was treated as if it doesn't belong to the line.

      • It's in some way logical, but seems to confuse people. Fixed.

      • per_file_comments:

        • mysql-test/r/gis-precise.result

        • mysql-test/t/gis-precise.test

        • sql/gcalc_tools.cc

          • Bug #857087arrow-up-right Wrong result with ST_INTERSECTS and LINESTRINGs

          • Point of line autointersection handled as it belongs to the line.

        • sql/gcalc_tools.h

    • Revision #2978.3.31arrow-up-right Fri 2011-09-23 15:36:56 +0500

      • Bug #857050arrow-up-right ST_WITHIN returns wrong result with MULTIPOINT and POLYGON actually only testcase added as the bug was fixed already.

      • modified:

        • mysql-test/r/gis-precise.result

        • mysql-test/t/gis-precise.test

        • sql/gcalc_tools.cc

          • superfluous variable removed.

    • Revision #2978.3.30arrow-up-right Fri 2011-09-23 15:25:48 +0500

      • fix for Bug #857051arrow-up-right ST_EQUALS returns TRUE on two nonidentical MULTIPOINTs

      • The 'single point' event was forgotten in the relation's calculation

      • per-file comments:

        • mysql-test/r/gis-precise.result

        • mysql-test/t/gis-precise.test

        • sql/gcalc_tools.cc

          • fix for Bug #857051arrow-up-right ST_EQUALS returns TRUE on two nonidentical MULTIPOINTs

          • scev_single_point is properly handled.

    • Revision #2978.3.29arrow-up-right Fri 2011-09-23 15:05:36 +0500

      • fix for 857050 ST_WITHIN returns wrong result with MULTIPOINT and POLYGON return GEOMETRYCOLLECTION EMPTY, not NULL for the query

      • per-file comments:

        • mysql-test/r/gis.result

          • fix for 857050 ST_WITHIN returns wrong result with MULTIPOINT and POLYGON test result updated.

        • sql/spatial.cc

          • fix for 857050 ST_WITHIN returns wrong result with MULTIPOINT and POLYGON return of the Geometry::envelope() changed for the empty geometry.

    • Revision #2978.3.28arrow-up-right Thu 2011-09-22 18:53:36 +0500

      • fixed bugs

      • Changed the way weird functions like Crosses or Touches treated.

      • Added BORDER handling to the Gcalc_function.

      • per-file comments:

        • mysql-test/r/gis-precise.result

          • GIS bugs fixed.

          • test result updated.

        • mysql-test/t/gis-precise.test

          • GIS bugs fixed.

          • test cases added.

        • sql/gcalc_slicescan.h

          • GIS bugs fixed.

        • sql/gcalc_tools.cc

          • GIS bugs fixed.

        • sql/gcalc_tools.h

          • GIS bugs fixed.

        • sql/item_create.cc

          • GIS bugs fixed.

        • sql/item_geofunc.cc

          • GIS bugs fixed.

        • sql/item_geofunc.h

          • GIS bugs fixed.

        • sql/spatial.cc

          • GIS bugs fixed.

    • Revision #2978.3.27arrow-up-right Wed 2011-09-21 13:26:21 +0500

    • Revision #2978.3.26arrow-up-right Wed 2011-09-21 12:50:03 +0500

      • fix for Bug #848926arrow-up-right GIS functions return "GEOMETRYCOLLECTION()" instead of "GEOMETRYCOLLECTION EMPTY"

      • per-file comments:

        • mysql-test/r/gis.result

          • fix for Bug #848926arrow-up-right GIS functions return "GEOMETRYCOLLECTION()" instead of "GEOMETRYCOLLECTION EMPTY"

          • test result updated.

        • mysql-test/t/gis.test

          • fix for Bug #848926arrow-up-right GIS functions return "GEOMETRYCOLLECTION()" instead of "GEOMETRYCOLLECTION EMPTY"

          • test case added.

        • sql/gstream.cc

          • fix for Bug #848926arrow-up-right GIS functions return "GEOMETRYCOLLECTION()" instead of "GEOMETRYCOLLECTION EMPTY"

          • lookup_next_word() implemented.

        • sql/gstream.h

          • fix for Bug #848926arrow-up-right GIS functions return "GEOMETRYCOLLECTION()" instead of "GEOMETRYCOLLECTION EMPTY"

          • lookup_next_word() added.

        • sql/spatial.cc

          • fix for Bug #848926arrow-up-right GIS functions return "GEOMETRYCOLLECTION()" instead of "GEOMETRYCOLLECTION EMPTY"

          • name changed for the empty geometry.

        • sql/spatial.h

          • fix for Bug #848926arrow-up-right GIS functions return "GEOMETRYCOLLECTION()" instead of "GEOMETRYCOLLECTION EMPTY"

          • declarations modified.

    • Revision #2978.3.25arrow-up-right Wed 2011-09-21 09:29:37 +0500

      • bugs fixed

      • per-file comments:

        • mysql-test/r/gis.result

          • test result updated.

        • mysql-test/t/gis.test

          • test case added for 850775.

        • sql/gcalc_slicescan.cc

          • compiler error fixed.

        • sql/spatial.cc

          • ST_AREA implementation for GEOMETRY_COLLECTION, POINT and LINESTRING.

        • sql/spatial.h

          • area() declarations added.

    • Revision #2978.3.24arrow-up-right Wed 2011-09-21 00:04:41 +0500

      • several bugs fixed here.

        • Bug #849789arrow-up-right Second assertion `m_poly_borders->next' failed in Gcalc_operation_reducer::count_slice in maria-5.3-gis

        • Bug #849791arrow-up-right Fourth assertion `n > 0 && n < SINUSES_CALCULATED*2+1' in get_n_sincos

        • Bug #849789arrow-up-right Second assertion `m_poly_borders->next' failed in Gcalc_operation_reducer::count_slice in maria-5.3-gis

        • Bug #848901arrow-up-right Assertion `fabs(cur_isc->x-m_cur_intersection->x) + fabs(cur_isc->y-m_cur_intersection->y) < 0.000000000001' failed in Gcalc_scan_iterator::intersection_scan() in maria-5.3-gis

      • per-file comments:

        • mysql-test/r/gis-precise.result

          • test result updated.

        • mysql-test/r/gis.result

          • test result updated.

        • sql/gcalc_slicescan.cc

          • bugfixes.

        • sql/gcalc_slicescan.h

          • bugfixes.

        • sql/gcalc_tools.cc

          • bugfixes.

        • sql/gcalc_tools.h

          • bugfixes.

        • sql/item_geofunc.cc

          • bugfixes.

        • sql/spatial.cc

          • bugfixes.

    • Revision #2978.3.23arrow-up-right Tue 2011-09-13 18:26:16 +0500

      • Fix for Bug #848939arrow-up-right Wrong result with ST_INTERSECTION between linestrings and a polygon in 5.3-gis

        • Coordinates were mistakenly reversed for MULTIPOINT.

      • per-file comments:

        • mysql-test/r/gis-precise.result

          • Fix for Bug #848939arrow-up-right Wrong result with ST_INTERSECTION between linestrings and a polygon in 5.3-gis

          • test result updated.

        • mysql-test/t/gis-precise.test

          • Fix for Bug #848939arrow-up-right Wrong result with ST_INTERSECTION between linestrings and a polygon in 5.3-gis

          • test case added.

        • sql/gcalc_tools.cc

          • Fix for Bug #848939arrow-up-right Wrong result with ST_INTERSECTION between linestrings and a polygon in 5.3-gis

          • coordinates set in the proper order.

    • Revision #2978.3.22arrow-up-right Tue 2011-09-13 15:19:55 +0500

      • Fix for Bug #848901arrow-up-right Assertion `fabs(cur_isc->x-m_cur_intersection->x) + fabs(cur_isc->y-m_cur_intersection->y) < 0.000000000001' failed in Gcalc_scan_iterator::intersection_scan() in maria-5.3-gis

      • That assertion's check was too tight. Released it a bit.

      • per-file comments:

    • Revision #2978.3.21arrow-up-right Tue 2011-09-13 13:59:11 +0500

      • Fix for few similar bugs:

        • Bug #841622arrow-up-right Assertion `t->rp->type == Gcalc_function::shape_line' failed in Gcalc_operation_reducer::end_line in maria-5.3-gi

        • Bug #841625arrow-up-right Assertion `m_poly_borders->next' failed in Gcalc_operation_reducer::count_slice in maria-5.3-gis

        • Bug #841638arrow-up-right Assertion `!m_prev || m_prev->x != x || m_prev->y != y' failed in Gcalc_shape_transporter::int_add_point in maria-5.3-gis

        • Bug #841662arrow-up-right Third assertion `n > 0 && n < SINUSES_CALCULATED*2+1' in get_n_sincos

        • Bug #841745arrow-up-right Assertion `!sp0->is_bottom()' failed in Gcalc_scan_iterator::find_intersections in maria-5.3-gis

      • They mostly was caused by inprecision of double arithmetic.

        • Fixed by changes in how to handle multiple intersections to keep their order right.

        • Also ST_DISTANCE(GEOM, EMPTY_GEOM) was defined as NULL.

      • per-file comments:

        • mysql-test/r/gis-precise.result

          • GIS bugfixes.

            • test result updated.

        • mysql-test/t/gis-precise.test

          • GIS bugfixes.

            • test cases added.

        • sql/gcalc_slicescan.cc

          • GIS bugfixes.

            • If intersections are close, add order checks to cope with the double calcualtions imprecision.

        • sql/gcalc_slicescan.h

          • GIS bugfixes.

            • n_row parameter added to intersection to check their order.

        • sql/item_geofunc.cc

          • GIS bugfixes.

            • ST_DISTANCE(GEOM, EMPTY_GEOM) returns NULL.

    • Revision #2978.3.20arrow-up-right Mon 2011-09-05 09:49:46 +0500

      • Bug #839327arrow-up-right Crash in Gcalc_operation_reducer::end_couple with ST_UNION and MULTIPOLYGONs in 5.3-gis.

      • When edges of a polygon coicide, it can form an pike, that is turned into a line after an operation.

      • In this case a former polygon point can be an end of a single line, and that case wasn't properly handled.

      • per-file comments:

        • mysql-test/r/gis-precise.result

          • Bug #839327arrow-up-right Crash in Gcalc_operation_reducer::end_couple with ST_UNION and MULTIPOLYGONs in 5.3-gis.

            • test result updated.

        • mysql-test/t/gis-precise.test

          • Bug #839327arrow-up-right Crash in Gcalc_operation_reducer::end_couple with ST_UNION and MULTIPOLYGONs in 5.3-gis.

            • test case added.

        • sql/gcalc_tools.cc

          • Bug #839327arrow-up-right Crash in Gcalc_operation_reducer::end_couple with ST_UNION and MULTIPOLYGONs in 5.3-gis.

            • in the scev_two_ends case check if we have single line ending on a polygon node.

    • Revision #2978.3.19arrow-up-right Mon 2011-09-05 09:13:58 +0500

      • Bug #839318arrow-up-right Crash in Gcalc_scan_iterator::point::get_shape with ST_DISTANCE and MULTILINESTRING in maria-5.3-gis.

        • wrong variable was used as a result of inattentive copypaste.

      • per-file comments:

        • mysql-test/r/gis-precise.result

          • Bug #839318arrow-up-right Crash in Gcalc_scan_iterator::point::get_shape with ST_DISTANCE and MULTILINESTRING in maria-5.3-gis.

          • test result updated.

        • mysql-test/t/gis-precise.test

          • Bug #839318arrow-up-right Crash in Gcalc_scan_iterator::point::get_shape with ST_DISTANCE and MULTILINESTRING in maria-5.3-gis.

          • test case added.

        • sql/item_geofunc.cc

          • Bug #839318arrow-up-right Crash in Gcalc_scan_iterator::point::get_shape with ST_DISTANCE and MULTILINESTRING in maria-5.3-gis.

          • use 'ev' variable instead of the 'evpos'.

    • Revision #2978.3.18arrow-up-right Sun 2011-09-04 23:48:17 +0500

      • Bug #839341arrow-up-right 100% CPU usage with ST_UNION in maria-5.3-gis.

        • Line loops weren't recognized when collect results.

        • Fixed by checking if we got the same beginning point of the line.

      • per-file comments:

        • mysql-test/r/gis-precise.result

        • mysql-test/t/gis-precise.test

        • sql/gcalc_tools.cc

          • Bug #839341arrow-up-right 100% CPU usage with ST_UNION in maria-5.3-gis.

          • check if we get the beginning node of the linestring, then cut the loop.

    • Revision #2978.3.17arrow-up-right Sun 2011-09-04 19:11:04 +0500

      • Bug #801466arrow-up-right ST_INTERSECTION() returns invalid value on empty intersection in maria-5.3-gis.

        • We didn't implement an empty geometry. And returning NULL instead of it is not quite correct. So here is the implementation of the empty value as GEOMETRYCOLLECTION().

      • per-file comments:

        • mysql-test/r/gis-precise.result

          • Bug #801466arrow-up-right ST_INTERSECTION() returns invalid value on empty intersection in maria-5.3-gis.

            • test result updated.

        • mysql-test/r/gis.result

          • Bug #801466arrow-up-right ST_INTERSECTION() returns invalid value on empty intersection in maria-5.3-gis.

            • test result updated.

        • mysql-test/t/gis-precise.test

        • mysql-test/t/gis.test

        • sql/field.cc

          • Bug #801466arrow-up-right ST_INTERSECTION() returns invalid value on empty intersection in maria-5.3-gis.

            • store GEOMETRYCOLLECTION() properly.

        • sql/gcalc_tools.cc

          • Bug #801466arrow-up-right ST_INTERSECTION() returns invalid value on empty intersection in maria-5.3-gis.

            • create the GEOMETRYCOLLECTION() for the empty result.

        • sql/gstream.h

          • Bug #801466arrow-up-right ST_INTERSECTION() returns invalid value on empty intersection in maria-5.3-gis.

            • next_symbol() added.

        • sql/spatial.cc

          • Bug #801466arrow-up-right ST_INTERSECTION() returns invalid value on empty intersection in maria-5.3-gis.

            • code modified to handle 0 geometries in the GEOMETRYCOLLECTION properly.

    • Revision #2978.3.16arrow-up-right Fri 2011-09-02 09:38:17 +0500

    • Revision #2978.3.15arrow-up-right Thu 2011-09-01 11:44:56 +0500

      • PostGIS-style 'same point' handling.

    • Revision #2978.3.14arrow-up-right Wed 2011-07-13 14:57:27 +0500

      • Fix for Bug #804266arrow-up-right Memory corruption/valgrind warning/crash in move_hole() with ST_UNION.

      • Second smaller hole in the polygon got link to the bigger one as it's the outer ring. Fixed by specifying the outer ring explicitly.

      • per-file comments:

        • mysql-test/r/gis-precise.result

        • mysql-test/t/gis-precise.test

        • sql/gcalc_tools.cc

          • Fix for Bug #804266arrow-up-right Memory corruption/valgrind warning/crash in move_hole() with ST_UNION.

            • specify the outer ring explicitly in the get_polygon_result parameter.

        • sql/gcalc_tools.h

          • Fix for Bug #804266arrow-up-right Memory corruption/valgrind warning/crash in move_hole() with ST_UNION.

            • add the outer ring as a parameter to the get_polygon_result.

    • Revision #2978.3.13arrow-up-right Tue 2011-07-12 11:21:20 +0500

      • Fix for Bug #801217arrow-up-right Assertion `t1->result_range' in Gcalc_operation_reducer::end_couple.

        • We cannot cut a line from a polygon. So if the polygon fits the condition, and the intersection of a line and the polygon doesn't, we just skip the line.

        • That rule wasn't applied if the line start was inside the polygon, which leaded to the assertion.

      • per-file comments:

        • mysql-test/r/gis-precise.result

        • mysql-test/t/gis-precise.test

        • sql/gcalc_tools.cc

          • Fix for Bug #801217arrow-up-right Assertion `t1->result_range' in Gcalc_operation_reducer::end_couple.

            • Don't mark the line as a border if it's inside a polygon that fits the result condition.

    • Revision #2978.3.12arrow-up-right Fri 2011-07-08 15:38:15 +0500

      • Fix for Bug #804259arrow-up-right Second assertion in Gis_geometry_collection::init_from_opresult.

        • A polygon has no right to have holes that are actually points.

        • So just skip them when we collect the result of an operation.

      • per-file comments:

        • mysql-test/r/gis-precise.result

        • mysql-test/t/gis-precise.test

        • sql/gcalc_tools.cc

          • Fix for Bug #804259arrow-up-right Second assertion in Gis_geometry_collection::init_from_opresult.

            • Skip the point in the result if it's the hole inside a polygon.

    • Revision #2978.3.11arrow-up-right Thu 2011-07-07 21:30:51 +0500

      • Fix for Bug #805860arrow-up-right Second assertion Assertion `n > 0 && n < SINUSES_CALCULATED*2+1' in get_n_sincos.

        • Just typo-style mistake. Should be '||' instead of '&&'.

      • per-file comments:

        • mysql-test/r/gis-precise.result

          • Fix for Bug #805860arrow-up-right Second assertion Assertion `n > 0 && n < SINUSES_CALCULATED*2+1' in get_n_sincos.

            • test result updated.

        • mysql-test/t/gis-precise.test

          • Fix for Bug #805860arrow-up-right Second assertion Assertion `n > 0 && n < SINUSES_CALCULATED*2+1' in get_n_sincos.

            • test case added.

        • sql/item_geofunc.cc

          • Fix for Bug #805860arrow-up-right Second assertion Assertion `n > 0 && n < SINUSES_CALCULATED*2+1' in get_n_sincos.

            • condition fixed.

    • Revision #2978.3.10arrow-up-right Thu 2011-07-07 16:59:45 +0500

      • Fix for Bug #804324arrow-up-right Assertion 0 in Gcalc_scan_iterator::pop_suitable_intersection

        • There were actually two bugs. One was when the line that intersects itself the intersection point treated as it doesn't belong to the line.

        • Second when edges partly coincide, wrong result produced when we try to find their intersection.

      • per-file comments:

        • mysql-test/r/gis-precise.result

        • mysql-test/t/gis-precise.test

        • sql/gcalc_slicescan.cc

          • Fix for Bug #804324arrow-up-right Assertion 0 in Gcalc_scan_iterator::pop_suitable_intersection

            • skip the intersection if it just line that intersects itself.

        • sql/gcalc_tools.cc

          • Fix for Bug #804324arrow-up-right Assertion 0 in Gcalc_scan_iterator::pop_suitable_intersection

            • if edges coincide, just pick the first coinciding poing as an intersection.

    • Revision #2978.3.9arrow-up-right Tue 2011-07-05 19:42:35 +0500

      • Bug #804305arrow-up-right Crash in wkb_get_double with ST_INTERSECTION.

      • That crash happened with the complicated topology of the result.

      • If we found a hole in a polygon whose outside border was already found, we need to paste the hole right after it and respectively shift polygons after it. Also we need to update poly_position fields in these polygons. That last thing wasn't properly done that led to the crash.

      • To fix that we keep the list of the found polygons and update the poly_positions that are bigger or equal to where we placed the next hole.

      • per-file comments:

        • mysql-test/r/gis-precise.result

        • mysql-test/t/gis-precise.test

        • sql/gcalc_tools.cc

          • Bug #804305arrow-up-right Crash in wkb_get_double with ST_INTERSECTION.

            • keep the list of the found polygons and update their poly_position fields respectively.

        • sql/gcalc_tools.h

    • Revision #2978.3.8arrow-up-right Mon 2011-07-04 16:17:34 +0500

      • fix for Bug #801212arrow-up-right Assertion with ST_INTERSECTION on NULL values

        • The ::val_str() method has to return NULL if it calculated the null_value, not just set the related flag.

      • per-file comments:

        • mysql-test/r/gis-precise.result

        • mysql-test/t/gis-precise.test

        • sql/item_geofunc.cc

          • fix for Bug #801212arrow-up-right Assertion with ST_INTERSECTION on NULL values

            • return NULL from the val_str if we get the null_value.

    • Revision #2978.3.7arrow-up-right Mon 2011-07-04 16:03:36 +0500

      • Bug #801199arrow-up-right Infinite recursion in Gcalc_function::count_internal with ST_BUFFER over MULTIPOINT

        • Collections were treated mistakenly, so the counter for the final UNION operation received the wrong value.

        • As a fix we implement Item_func_buffer::Transporter::start_collection() method, where we set the proper operation and the operand counter. start_poly() and start_line() were also modified to function correctly for the polygon as a part of a collection.

      • per-file comments:

        • mysql-test/r/gis-precise.result

          • Bug #801199arrow-up-right Infinite recursion in Gcalc_function::count_internal with ST_BUFFER over MULTIPOINT

            • test result updated.

        • mysql-test/t/gis-precise.test

          • Bug #801199arrow-up-right Infinite recursion in Gcalc_function::count_internal with ST_BUFFER over MULTIPOINT

            • test case added.

        • sql/item_geofunc.cc

          • Bug #801199arrow-up-right Infinite recursion in Gcalc_function::count_internal with ST_BUFFER over MULTIPOINT

            • start_collection() implemented.

        • sql/item_geofunc.h

          • Bug #801199arrow-up-right Infinite recursion in Gcalc_function::count_internal with ST_BUFFER over MULTIPOINT

            • Item_func_buffer::Transporter::start_collection() defined.

    • Revision #2978.3.6arrow-up-right Thu 2011-06-30 19:24:52 +0500

      • fix for Bug #201189arrow-up-right ST_BUFFER asserts if radius = 0.

        • Internal caclucations can't handle zero distance properly.

        • As the ST_BUFFER(geom, 0) is in fact NOOP, we'll just return the

          • 'geom' as the result here.

      • per-file comments:

        • mysql-test/r/gis-precise.result

        • mysql-test/t/gis-precise.test

        • sql/item_geofunc.cc

          • fix for Bug #201189arrow-up-right ST_BUFFER asserts if radius = 0.

            • return the first argument as the result of the ST_BUFFER, if the distance is 0 there.

    • Revision #2978.3.5arrow-up-right Thu 2011-06-30 18:18:27 +0500

      • fix for Bug #801243arrow-up-right Assertion `(0)' failed in Gis_geometry_collection::init_from_opresult on ST_UNION

        • If the result contains a polygon with a hole, consequitive shapes weren't calculated properly, as the hole appeared as shape in the result, but actually it's a single shape with the surrounding polygon. It's more natural to use the size of the result as a border instead of the number of resulting shapes.

      • per-file comments:

        • mysql-test/r/gis-precise.result

          • fix for Bug #801243arrow-up-right Assertion `(0)' failed in Gis_geometry_collection::init_from_opresult on ST_UNION

          • test result updated.

        • mysql-test/t/gis-precise.test

          • fix for Bug #801243arrow-up-right Assertion `(0)' failed in Gis_geometry_collection::init_from_opresult on ST_UNION

          • test case added.

        • sql/spatial.cc

          • fix for Bug #801243arrow-up-right Assertion `(0)' failed in Gis_geometry_collection::init_from_opresult on ST_UNION

          • check the data lenght instead of number of shapes.

        • sql/spatial.h

          • fix for Bug #801243arrow-up-right Assertion `(0)' failed in Gis_geometry_collection::init_from_opresult on ST_UNION

          • check the data lenght instead of number of shapes.

    • Revision #2978.3.4arrow-up-right [merge] Mon 2011-06-20 00:21:41 +0500

  • Revision #3287arrow-up-right Thu 2011-11-17 01:00:46 -0800

  • Revision #3286arrow-up-right Thu 2011-11-17 01:25:10 +0200

    • Fix Bug #869036arrow-up-right

    • Apart from the fix, the patch also adds few more unrelated test cases for partial matching, and fixes few typos.

    • Analysis:

      • This bug uncovered that partial matching via rowid intersection didn't handle the case when:

        • the left IN argument has some NULLs,

        • there are no non-null value matches, and there is no non-null column,

        • the subquery columns that are not covered with the NULLs in the left IN argument contain at least one row, such that it has NULL values in all columns where the left IN operand has no NULLs.

      • In this case there is a partial match.

      • In addition the analysis of the related code uncovered incorrect handling of few other related cases.

    • Solution:

      • The solution for the bug is to check if there exists a row with NULLs in all columns other than the ones having NULL in the let IN operand.

      • The check is implemented via checking whether the bitmaps that store NULL information in class Ordered_key have a non-empty intersection for the relevant columns.

      • The intersection itself is implemented via the function bitmap_exists_intersection() in my_bitmap.c.

  • Revision #3285arrow-up-right Wed 2011-11-16 06:11:25 -0800

    • Fixed Bug #887479arrow-up-right.

    • The function setup_semijoin_dups_elimination erroneously assumed that if join_cache_level is set to 3 or 4 then the type of the access to a table cannot be JT_REF or JT_EQ_REF. This could lead to wrong query result sets.

  • Revision #3284arrow-up-right [merge] Tue 2011-11-15 14:35:36 -0800

    • Merge.

    • Revision #3278.1.1arrow-up-right Tue 2011-11-15 13:03:00 -0800

      • Fixed Bug #889750arrow-up-right.

      • If the optimizer switch 'semijoin_with_cache' is set to 'off' then join cache cannot be used to join inner tables of a semijoin.

      • Also fixed a bug in the function check_join_cache_usage() that led to wrong output of the EXPLAIN commands for some test cases.

  • Revision #3283arrow-up-right Mon 2011-11-14 19:24:36 +0200

    • Fix Bug #889744arrow-up-right

    • MariaDB 5.5 merges changes from MySQL 5.5 where all constant expressions are wrapped into an Item_cache. As a result, constant single-row subqueries were also wrapped in an Item_cache. When analyzing the where clause for constant expressions that can be evaluated during optimization, subqueries wrapped into an Item_cache did not appear as expensive, and were therefore evaluated during optimization. Such evaluation is against the current architecture of MariaDB 5.3 where subquries are executed during the execute phase.

    • The patch adds the is_expensive() predicate to Item_cache.

    • This makes Item_cache consistent with other wrapping Item classes that need to look at the properties of the wrapped object.

  • Revision #3282arrow-up-right [merge] Mon 2011-11-14 00:32:21 +0100

  • Revision #3281arrow-up-right Sun 2011-11-13 12:02:13 +0200

    • Fix for Bug #824425arrow-up-right: Prohibiting subqueries in rows for left part of IN/ALL/ANY

    • Fix for walk() method of subqueries: always call the method on the subquery.

  • Revision #3280arrow-up-right [merge] Sun 2011-11-13 09:10:45 +0100

  • Revision #3279arrow-up-right [merge] Sat 2011-11-12 18:08:12 +0100

  • Revision #3278arrow-up-right [merge] Sat 2011-11-12 03:57:46 -0800

    • Merge.

    • Revision #3148.1.1arrow-up-right Sat 2011-11-12 02:20:44 -0800

      • Fixed Bug #823301arrow-up-right

      • A bug in the code of the function key_or could lead to a situation when performing of an OR operation for one index changes the result the operation for another index. This bug is fixed with this patch.

      • Also corrected the specification and the code of the function or_sel_tree_with_checks.

  • Revision #3277arrow-up-right Sat 2011-11-12 12:03:27 +0200

    • Remove unused variable detected by GCC 4.6.1.

  • Revision #3276arrow-up-right Sat 2011-11-12 11:29:12 +0200

    • Fix MySQL Bug #12329653arrow-up-right

      • In MariaDB, when running in ONLY_FULL_GROUP_BY mode, the server produced in incorrect error message that there is an aggregate function without GROUP BY, for artificially created MIN/MAX functions during subquery MIN/MAX optimization.

      • The fix introduces a way to distinguish between artifially created MIN/MAX functions as a result of a rewrite, and normal ones present in the query. The test for ONLY_FULL_GROUP_BY violation now tests in addition if a MIN/MAX function was part of a MIN/MAX subquery rewrite.

      • In order to be able to distinguish these MIN/MAX functions, the patch introduces an additional flag in Item_in_subselect::in_strategy - SUBS_STRATEGY_CHOSEN. This flag is set when the optimizer makes its final choice of a subuqery strategy. In order to make the choice consistent, access to Item_in_subselect::in_strategy is provided via new class methods.

    • Fix MySQL Bug #12329653arrow-up-right

      • In MariaDB, when running in ONLY_FULL_GROUP_BY mode, the server produced in incorrect error message that there is an aggregate function without GROUP BY, for artificially created MIN/MAX functions during subquery MIN/MAX optimization.

      • The fix introduces a way to distinguish between artifially created MIN/MAX functions as a result of a rewrite, and normal ones present in the query. The test for ONLY_FULL_GROUP_BY violation now tests in addition if a MIN/MAX function was part of a MIN/MAX subquery rewrite.

      • In order to be able to distinguish these MIN/MAX functions, the patch introduces an additional flag in Item_in_subselect::in_strategy - SUBS_STRATEGY_CHOSEN. This flag is set when the optimizer makes its final choice of a subuqery strategy. In order to make the choice consistent, access to Item_in_subselect::in_strategy is provided via new class methods.

  • Revision #3275arrow-up-right Fri 2011-11-11 14:53:26 -0800

    • Fixed Bug #879871arrow-up-right

    • The function add_ref_to_table_cond missed updating the value of join_tab->pre_idx_push_select_cond after having updated the value of join_tab->select->pre_idx_push_select_cond.

  • Revision #3274arrow-up-right [merge] Thu 2011-11-10 13:28:02 -0800

  • Revision #3273arrow-up-right Mon 2011-11-07 16:39:02 +0400

    • Make subselect_extra_no_semijoin.test run the tests with semijoin=off,

    • update test results

  • Revision #3272arrow-up-right Fri 2011-11-04 12:04:12 +0200

    • Fixed that test doesn't abort if 'var' points to a deleted directory (common case when using --mem)

    • Better error message if --log-bin is used without --log-bin-index

  • Revision #3271arrow-up-right Fri 2011-11-04 10:14:25 +0200

  • Revision #3270arrow-up-right Thu 2011-11-03 13:00:25 +0100

    • rename binlog_dbug_fsync_sleep -> debug_binlog_fsync_sleep

  • Revision #3269arrow-up-right Thu 2011-11-03 12:59:48 +0100

    • cast.test: use exact double, to be independent from compiler optimizations

  • Revision #3268arrow-up-right [merge] Wed 2011-11-02 22:06:22 +0400

  • Revision #3267arrow-up-right Wed 2011-11-02 20:01:50 +0400

    • Change the default @@optimizer_switch settings:

      • More test result updates (the errors are the same, the difference is that "at row X" became "at row Y" due to queries with semi-joins producing select results in different order)

  • Revision #3266arrow-up-right Wed 2011-11-02 19:52:11 +0400

    • Fix "unused variable addr" warning

  • Revision #3265arrow-up-right [merge] Wed 2011-11-02 19:37:26 +0400

  • Revision #3264arrow-up-right [merge] Wed 2011-11-02 13:51:47 +0400

  • Revision #3263arrow-up-right [merge] Wed 2011-11-02 10:05:07 +0200

  • Revision #3262arrow-up-right Tue 2011-11-01 18:19:19 +0200

    • Fix Bug #833702arrow-up-right

    • Analysis:

      • Equality propagation propagated the constant '7' into args[0] of the Item_in_optimizer that stands for the "< ANY" predicate. At the same the min/max subquery rewrite swapped the order of the left and right operands of the "<" predicate, but used Item_in_subselect::left_expr.

      • As a result, when the <ANY predicate is executed early in the execution phase as a contant condition, instead of a constant right (swapped) argument of the < predicate, there was a field (t3.a). This field had no data, since the whole predicate is considered constant, and it is evaluated before any tables are read. Having junk in the field row buffer produced wrong result

    • Solution:

      • Fix create_swap to pick the correct Item_in_optimizer left argument.

  • Revision #3261arrow-up-right Tue 2011-11-01 13:22:09 +0200

    • Fix of typo.

  • Revision #3260arrow-up-right Tue 2011-11-01 12:04:11 +0400

    • Bug #884631arrow-up-right: Table elimination works 5.3 release builds even if turned off

      • Make table elimination to actually switch itself on/off in release builds.

  • Revision #3259arrow-up-right Mon 2011-10-31 15:07:43 +0400

    • Bug #882994arrow-up-right: Crash in QUICK_RANGE_SELECT::reset with derived_with_keys

      • The bug was caused by the following scenario:

        • a quick select is created with get_quick_select_for_ref. The quick select refers to temporary (derived) table. It saves table->file, which refers to a ha_heap object.

        • When temp table is populated, ha_heap reaches max. size and is converted to a ha_myisam. However, quick->file remains pointing to where ha_heap was.

        • Attempt to use the quick select causes crash.

          • Fixed by introducing QUICK_SELECT_I::replace_handler(). Note that it will not work for index_merge quick selects. Which is fine, because these quick selects are never created for derived tables.

  • Revision #3258arrow-up-right Fri 2011-10-28 12:38:36 +0400

    • Let t/myisam_icp.test run include/icp_tests.inc with MRR/ICP turned ON (not OFF)

    • Fix the compile-time-default value of optimizer_switch printed by mysqld --help --defaults

  • Revision #3257arrow-up-right Fri 2011-10-28 11:23:30 +0400

    • Make innodb_no_mrricp.test to really run with MRR and ICP turned OFF.

  • Revision #3256arrow-up-right Thu 2011-10-27 12:03:33 -0700

  • Revision #3255arrow-up-right [merge] Thu 2011-10-27 09:14:45 -0700

    • Merge.

    • Revision #3252.1.1arrow-up-right Thu 2011-10-27 08:32:24 -0700

      • Fixed Bug #874035arrow-up-right

      • The function Item_direct_view_ref::fix_fields erroneously did not correct the value of the flag maybe_null when the view for which the item was being fixed happened to be an inner table of an outer join.

  • Revision #3254arrow-up-right Thu 2011-10-27 13:54:28 +0400

    • Bug #882472arrow-up-right: subselect4.test fails in current 5.3

      • The problem was that the value of READ_RECORD::file was not updated when the underlying table was temporary and was converted from heap to myisam. Resolved by eliminating READ_RECORD::file, always use READ_RECORD::table->file

  • Revision #3253arrow-up-right Wed 2011-10-26 20:25:18 +0300

    • Fixed Bug #879939arrow-up-right "assertion in ha_maria::enable_indexes with derived_with_keys=on"

    • Honor unique/not unique when creating keys for internal tempory tables.

    • Added new variables to be used to limit how keys are created for internal temporary tables.

  • Revision #3252arrow-up-right Wed 2011-10-26 04:27:09 -0700

    • Fixed Bug #881449arrow-up-right

    • The function SELECT_LEX::update_used_tables first must clean up all bitmaps to be recalculated for all tables that require it and only after this walk through on conditions attached to the tables to update these bitmaps.

  • Revision #3251arrow-up-right [merge] Wed 2011-10-26 10:58:40 +0400

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

    • Revision #3249.1.1arrow-up-right Wed 2011-10-26 02:38:49 +0400

      • Bug #877288arrow-up-right: Wrong result with semijoin + materialization + multipart key

        • when create_ref_for_key() is constructing a ref access for a table that's inside a SJ-Materialization nest, it may not use references to fields of tables that are unside the nest (because these fields will not yet have values when ref access will be used)

        • The check was performed in the first of create_ref_for_key's loops (the one which counts how many key parts are usable) but not in the second (the one which actually fills the TABLE_REF structure).

  • Revision #3250arrow-up-right Tue 2011-10-25 14:18:19 -0700

    • Fixed Bug #881318arrow-up-right.

    • If a materialized derived table / view is empty then for this table the value of file->ref is 0. This was not taken into account by the function JOIN_CACHE::write_record_data. As a result a query using an empty materialized derived tables as inner tables of outer joins and IN subqueries in WHERE conditions could cause server crashes when the optimizer employed join caches and duplicate elimination for semi-joins.

  • Revision #3249arrow-up-right Mon 2011-10-24 12:54:28 -0700

  • Revision #3248arrow-up-right Sun 2011-10-23 05:46:03 -0700

    • Fixed Bug #879882arrow-up-right

    • This bug happened because the function Item_cond::eval_not_null_tables erroneously did not initialize the value of not_null_tables_cache.

  • Revision #3247arrow-up-right Sat 2011-10-22 07:19:43 -0700

    • Fixed Bug #878769arrow-up-right

    • The method DsMrr_impl::dsmrr_init erroneously tried to get a KEY descriptor for key with number MAX_KEY. This caused valgrind complains.

  • Revision #3246arrow-up-right Sat 2011-10-22 00:14:27 -0700

    • Fixed Bug #874378arrow-up-right

    • This bug happened for the queries over multi-table mergeable views because the bitmap TABLE::read_set of the underlying tables were not updated after the views had been merged into the query.

    • Now this bitmaps are updated properly.

    • Also the bitmap TABLE::merge_keys now is updated in prevention of future bugs.

  • Revision #3245arrow-up-right Thu 2011-10-20 08:02:31 -0700

  • Revision #3244arrow-up-right Thu 2011-10-20 04:59:20 -0700

    • Fixed Bug #878199arrow-up-right

    • The function JOIN::drop_unused_derived_keys could erroneously set the value of REF::key to 0 for a joined materialized view/derived table in the case when no REF access to the table was used by the query execution plan. This could cause a crash of the server.

  • Revision #3243arrow-up-right [merge] Wed 2011-10-19 23:35:11 -0700

  • Revision #3242arrow-up-right [merge] Wed 2011-10-19 21:01:42 +0200

  • Revision #3241arrow-up-right Tue 2011-10-18 22:50:17 +0300

    • Fix of building on Mac OS.

  • Revision #3240arrow-up-right [merge] Tue 2011-10-18 14:04:10 +0300

  • Revision #3239arrow-up-right Mon 2011-10-17 03:42:56 -0700

    • Fixed a compiler warning.

  • Revision #3238arrow-up-right [merge] Mon 2011-10-17 01:20:16 -0700

    • Merge.

    • Revision #3235.1.1arrow-up-right Sun 2011-10-16 13:23:57 -0700

      • Fixed Bug #874006arrow-up-right

      • This bug manifested itself with queries containing non-correlated IN subqueries over materialized views/derived tables.

      • The bug happened because the code of the function generate_derived_keys did not take into account that the function could be called twice when the optimizer was deciding whether in-exist transformation should be applied.

  • Revision #3237arrow-up-right Sun 2011-10-16 22:46:11 +0300

    • Remove extra MariaDB- from binary tar.gz file name

    • Print server version name to .err file on crash

  • Revision #3236arrow-up-right Fri 2011-10-14 17:51:16 +0200

    • In crash handler, output session value of the optimizer switch.

  • Revision #3235arrow-up-right [merge] Fri 2011-10-14 03:56:41 -0700

  • Revision #3234arrow-up-right Fri 2011-10-14 12:41:20 +0200

    • update pbxt test results

  • Revision #3233arrow-up-right Thu 2011-10-13 13:44:50 +0200

  • Revision #3232arrow-up-right Thu 2011-10-13 11:23:59 +0200

    • typo.

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
PreviousMariaDB 5.3.4 ChangelogNextMariaDB 5.3.2 Changelog

Last updated

Was this helpful?