1. 16 May, 2012 3 commits
    • Michael Widenius's avatar
      Fixed LP:990187 Assertion `share->reopen == 1' failed at maria_extra on ADD PARTITION · 73fdf95b
      Michael Widenius authored
      
      mysql-test/suite/maria/maria-partitioning.result:
        New test case
      mysql-test/suite/maria/maria-partitioning.test:
        New test case
      sql/sql_base.cc:
        Ignore HA_EXTRA_NORMAL for wait_while_table_is_used()
        More DBUG
      sql/sql_partition.cc:
        Don't use HA_EXTRA_FORCE_REOPEN for wait_while_table_is_used() as the table is opened multiple times (in prep_alter_part_table)
        This fixes the assert in Aria where we check if table is opened multiple times if HA_EXTRA_FORCE_REOPEN is issued
      73fdf95b
    • Michael Widenius's avatar
      Moved maria tests to suite/maria · 1994d9ce
      Michael Widenius authored
      1994d9ce
    • Michael Widenius's avatar
      Fixed bug LP:973039 - Assertion `share->in_trans == 0' failed in maria_close... · 91bf357b
      Michael Widenius authored
      Fixed bug LP:973039 - Assertion `share->in_trans == 0' failed in maria_close on DROP TABLE under LOCK
      - 5.5 was missing calls to ha_extra(HA_PREPARE_FOR_DROP | HA_PREPARE_FOR_RENAME);  Lost in merge 5.3 -> 5.5
      
      
      sql/sql_admin.cc:
        Updated arguments for close_all_tables_for_name
      sql/sql_base.h:
        Updated arguments for close_all_tables_for_name
      sql/sql_partition.cc:
        Updated arguments for close_all_tables_for_name
      sql/sql_table.cc:
        Updated arguments for close_all_tables_for_name
        Removed test of kill, as we have already called 'ha_extra(HA_PREPARE_FOR_DROP)' and the table may be inconsistent.
      sql/sql_trigger.cc:
        Updated arguments for close_all_tables_for_name
      sql/sql_truncate.cc:
        For truncate that is done with drop + recreate, signal that the table will be dropped.
      91bf357b
  2. 15 May, 2012 1 commit
  3. 08 May, 2012 1 commit
  4. 07 May, 2012 2 commits
  5. 05 May, 2012 4 commits
  6. 04 May, 2012 5 commits
  7. 03 May, 2012 3 commits
  8. 02 May, 2012 1 commit
  9. 03 May, 2012 1 commit
  10. 02 May, 2012 8 commits
  11. 29 Apr, 2012 1 commit
    • Alexey Botchkov's avatar
      bug #977021 ST_BUFFER fails with the negative D. · 015c584c
      Alexey Botchkov authored
        Points and lines should disappear if we got negative D.
        To make it work properly inside the GEOMETRYCOLLECTION,
        we add the empty operation there.
      
      bug #986977 Assertion `!cur_p->event' failed in Gcalc_scan_iterator::arrange_event(int, int).
        The double->inernal coord conversion produced -0 (minus zero) on some data.
        That minus-zero produces invalid comparison results when compared agains plus-zero.
        So we fixed the gcalc_set_double() to avoid it.
      
      per-file comments:
        mysql-test/r/gis-precise.result
              result updated.
        mysql-test/t/gis-precise.test
              tests for #977021 and #986977 added.
        sql/gcalc_slicescan.cc
              bug #986977. The gcalc_set_double fixed to not produce minus-zero.
        sql/item_geofunc.cc
              bug #977021. Add the NOOP for the disappearing features.
      015c584c
  12. 26 Apr, 2012 1 commit
  13. 27 Apr, 2012 1 commit
    • unknown's avatar
      Fix bug lp:985667, MDEV-229 · a4336eb6
      unknown authored
      Analysis:
      
      The reason for the wrong result is the interaction between constant
      optimization (in this case 1-row table) and subquery optimization.
      
      - First the outer query is optimized, and 'make_join_statistics' finds that
      table t2 has one row, reads that row, and marks the whole table as constant.
      This also means that all fields of t2 are constant.
      
      - Next, we optimize the subquery in the end of the outer 'make_join_statistics'.
      The field 'f2' is considered constant, with value '3'. The subquery predicate
      is rewritten as the constant TRUE.
      
      - The outer query execution detects early that the whole query result is empty
      and calls 'return_zero_rows'. Since the query is with implicit grouping, we
      have to produce one row with special values for the aggregates (depending on
      each aggregate function), and NULL values for all non-aggregate fields.  This
      function calls 'no_rows_in_result' to set each aggregate function to the
      default value when it aggregates over an empty result, and then calls
      'send_data', which in turn evaluates each Item in the SELECT list.
      
      - When evaluation reaches the subquery predicate, it executes the subquery
      with field 'f2' having a constant value '3', and the subquery produces the
      incorrect result '7'.
      
      Solution:
      
      Implement Item::no_rows_in_result for all subquery predicates. In order to
      make this work, it is also needed to make all val_* methods of all subquery
      predicates respect the Item_subselect::forced_const flag. Otherwise subqueries
      are executed anyways, and override the default value set by no_rows_in_result
      with whatever result is produced from the subquery evaluation.
      a4336eb6
  14. 25 Apr, 2012 1 commit
  15. 24 Apr, 2012 1 commit
  16. 23 Apr, 2012 2 commits
  17. 20 Apr, 2012 1 commit
    • Vladislav Vaintroub's avatar
      LPBUG#983285 - incompatibility in frm in case of VIEWs with non-default ALGORITHM option. · a1492330
      Vladislav Vaintroub authored
      As part of derived tables redesign, values for VIEW_ALGORITHM_MERGE and VIEW_ALGORITHM_TMPTABLE have changed from (former values 1 rsp 2 , new values 5 rsp 9).
      
      This lead to the problem that views, created with version 5.2  or earlier would not work in all situations  (e.g "SHOW CREATE VIEW"), or with mysqldump.
      
      The fix is to restore backward compatibility for the from file, and convert algorithm={1,2} in the frm to {5,9} when reading .frm from disk, and store backward compatible values when writing from to disk. 
      
      Also allow processing correct processing for "invalid" .frms created with MariaDB 5.3/5.5 GA releases (where algorithm stored in memory matched the one stored in frm).
      a1492330
  18. 19 Apr, 2012 1 commit
  19. 29 Apr, 2012 1 commit
    • Alexey Botchkov's avatar
      bug #977021 ST_BUFFER fails with the negative D. · 52504f53
      Alexey Botchkov authored
        Points and lines should disappear if we got negative D.
        To make it work properly inside the GEOMETRYCOLLECTION,
        we add the empty operation there.
      
      bug #986977 Assertion `!cur_p->event' failed in Gcalc_scan_iterator::arrange_event(int, int).
        The double->inernal coord conversion produced -0 (minus zero) on some data.
        That minus-zero produces invalid comparison results when compared agains plus-zero.
        So we fixed the gcalc_set_double() to avoid it.
      
      per-file comments:
        mysql-test/r/gis-precise.result
              result updated.
        mysql-test/t/gis-precise.test
              tests for #977021 and #986977 added.
        sql/gcalc_slicescan.cc
              bug #986977. The gcalc_set_double fixed to not produce minus-zero.
        sql/item_geofunc.cc
              bug #977021. Add the NOOP for the disappearing features.
      52504f53
  20. 21 Apr, 2012 1 commit