1. 18 May, 2012 1 commit
    • Michael Widenius's avatar
      Fixed lp:997460 Truncate table on partitioned Aria table fails with ER_ILLEGAL_HA · 88accb77
      Michael Widenius authored
      Fix is done by doing an autocommit in truncate table inside Aria
      
      storage/maria/ha_maria.cc:
        Force a commit for TRUNCATE TABLE inside lock tables
        Check that we don't call TRUNCATE with concurrent inserts going on.
        Make ha_maria::implict_commit faster when we don't have Aria tables in the transaction.
        (Most of the patch is just re-indentation because I removed an if level)
      88accb77
  2. 16 May, 2012 4 commits
    • Michael Widenius's avatar
      More fixes for LOCK TABLE and REPAIR/FLUSH · 598bb174
      Michael Widenius authored
      Changed HA_EXTRA_NORMAL to HA_EXTRA_NOT_USED (more clean)
      
      mysql-test/suite/maria/lock.result:
        More extensive tests of LOCK TABLE with FLUSH and REPAIR
      mysql-test/suite/maria/lock.test:
        More extensive tests of LOCK TABLE with FLUSH and REPAIR
      sql/sql_admin.cc:
        Fix that REPAIR TABLE ... USE_FRM works with LOCK TABLES
      sql/sql_base.cc:
        Ensure that transactions are closed in ARIA when doing flush
        HA_EXTRA_NORMAL -> HA_EXTRA_NOT_USED
        Don't call extra many times for a table in close_all_tables_for_name()
        Added test if table_list->table as this can happen in error situations
      sql/sql_partition.cc:
        HA_EXTRA_NORMAL -> HA_EXTRA_NOT_USED
      sql/sql_reload.cc:
        Fixed comment
      sql/sql_table.cc:
        HA_EXTRA_NORMAL -> HA_EXTRA_NOT_USED
      sql/sql_trigger.cc:
        HA_EXTRA_NORMAL -> HA_EXTRA_NOT_USED
      sql/sql_truncate.cc:
        HA_EXTRA_FORCE_REOPEN -> HA_EXTRA_PREPARE_FOR_DROP for truncate, as this speeds up truncate by not having to flush the cache to disk.
      598bb174
    • 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
  3. 15 May, 2012 1 commit
  4. 08 May, 2012 1 commit
  5. 07 May, 2012 2 commits
  6. 05 May, 2012 4 commits
  7. 04 May, 2012 5 commits
  8. 03 May, 2012 3 commits
  9. 02 May, 2012 1 commit
  10. 03 May, 2012 1 commit
  11. 02 May, 2012 8 commits
  12. 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
  13. 26 Apr, 2012 1 commit
  14. 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
  15. 25 Apr, 2012 1 commit
  16. 24 Apr, 2012 1 commit
  17. 23 Apr, 2012 2 commits
  18. 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
  19. 19 Apr, 2012 1 commit