1. 10 Jun, 2018 13 commits
  2. 09 Jun, 2018 1 commit
    • Varun Gupta's avatar
      MDEV-16374: Filtered shows 0 for materilization scan for a semi join, which... · cd33280b
      Varun Gupta authored
      MDEV-16374: Filtered shows 0 for materilization scan for a semi join, which makes optimizer always picks
      materialization scan over materialization lookup
      
      For non-mergeable semi-joins we don't store the estimates of the IN subquery in table->file->stats.records.
      In the function TABLE_LIST::fetch_number_of_rows, we store the number of rows in the tables
      (estimates in case of derived table/views).
      Currently we don't store the estimates for non-mergeable semi-joins, which leads to a problem of selecting
      materialization scan over materialization lookup.
      Fixed this by storing these estimated appropriately
      cd33280b
  3. 08 Jun, 2018 3 commits
  4. 07 Jun, 2018 1 commit
    • Chris Calender's avatar
      MDEV-15789 - mysqlslap use incorrect table def · d9b159a2
      Chris Calender authored
      The bug arises when one uses --auto-generate-sql-guid-primary (and
      --auto-generate-sql-secondary-indexes) with mysqlslap and also have
      sql_mode=STRICT_TRANS_TABLE.
      
      When using this option, mysqlslap should create a column with varchar(36),
      but it appears to create it as a varchar(32) only. Then if one has
      sql_mode=STRICT_TRANS_TABLES, it throws an error, like:
      
        mysqlslap: Cannot run query INSERT INTO t1 VALUES (...)
        ERROR : Data too long for column 'id' at row 1
      
      Upstream bug report: BUG#80329.
      d9b159a2
  5. 06 Jun, 2018 1 commit
  6. 05 Jun, 2018 2 commits
    • Vladislav Vaintroub's avatar
      MDEV-10246 ssl-* config file options have no effect without mysql_ssl_set() · 72b6d018
      Vladislav Vaintroub authored
      Partially revert 4ef74979
      that caused regression.
      
      Any ssl- option must imply use_ssl=1, even if mysql_set_ssl() was not
      used.
      72b6d018
    • Marko Mäkelä's avatar
      MDEV-16124 fil_rename_tablespace() times out and crashes server during table-rebuilding ALTER TABLE · 55abcfa7
      Marko Mäkelä authored
      InnoDB insisted on closing the file handle before renaming a file.
      Renaming a file should never be a problem on POSIX systems. Also on
      Windows it should work if the file was opened in FILE_SHARE_DELETE
      mode.
      
      fil_space_t::stop_ios: Remove. We no longer need to stop file access
      during rename operations.
      
      fil_mutex_enter_and_prepare_for_io(): Remove the wait for stop_ios.
      
      fil_rename_tablespace(): Remove the retry logic; do not close the
      file handle. Remove the unused fault injection that was added along
      with the DATA DIRECTORY functionality (MySQL WL#5980).
      
      os_file_create_simple_func(), os_file_create_func(),
      os_file_create_simple_no_error_handling_func(): Include FILE_SHARE_DELETE
      in the share_mode. (We will still prevent multiple InnoDB instances
      from using the same files by not setting FILE_SHARE_WRITE.)
      55abcfa7
  7. 02 Jun, 2018 1 commit
    • Varun Gupta's avatar
      MDEV-16225: wrong resultset from query with semijoin=on · 5fb2c586
      Varun Gupta authored
      For non-semi-join subquery optimization we do a cost based decision between
      Materialisation and IN -> EXIST transformation. The issue in this case is that for IN->EXIST transformation
      we run JOIN::reoptimize with the IN->EXISt conditions and we come up with a new query plan. But when we compare
      the cost with Materialization, we make the decision to chose Materialization so we need to restore the query plan
      for Materilization.
      The saving and restoring for keyuse array and join_tab keyuse is only done when we have atleast
      one element in the keyuse_array , we are now changing to do it even for 0 elements to main the generality.
      5fb2c586
  8. 24 May, 2018 1 commit
  9. 23 May, 2018 2 commits
  10. 22 May, 2018 4 commits
    • Monty's avatar
      MDEV-15308 Assertion `ha_alter_info->alter_info->drop_list.elements · 908676df
      Monty authored
      Problem was that handle_if_exists_options() didn't correct
      alter_info->flags when things was removed from the list.
      908676df
    • Monty's avatar
      MDEV-16229 Replication aborts with ER_VIEW_SELECT_TMPTABLE after half-failed RENAME · da71c1ba
      Monty authored
      Problem was that detection of temporary tables was all wrong for
      RENAME TABLE.
      (Temporary tables where opened by top level call to
      open_temporary_tables(), which can't detect if a temporary table
      was renamed to something and then reused).
      
      Fixed by adding proper parsing of rename list to check against
      the current name of a table at each rename stage.
      Also change do_rename_temporary() to check against the current
      state of temporary tables, not according to the state of start
      of RENAME TABLE.
      da71c1ba
    • Monty's avatar
      Fixes for Aria transaction handling with lock tables · 2f3779d3
      Monty authored
      MDEV-10130 Assertion `share->in_trans == 0' failed in storage/maria/ma_close.c
      MDEV-10378 Assertion `trn' failed in virtual int ha_maria::start_stmt
      
      The problem was that maria_handler->trn was not properly reset
      at commit/rollback and ha_maria::exernal_lock() could get confused
      because.
      
      There was some old code in ha_maria::implicit_commit() that tried
      to take care of this, but it was not bullet proof.
      
      Fixed by adding list of all tables that is part of the maria transaction to
      TRN.
      
      A nice side effect was of the fix is that loops in
      ha_maria::implict_commit() got to be much simpler.
      
      Other things:
      - Fixed a bug in mysql_admin_table() where argument open_for_modify
        was wrongly reset for the next table in the chain
      - rollback admin command also in case of fatal error.
      - Split _ma_set_trn_for_table() to three version to simplify code
        and debugging.
      - Several new asserts to detect the original problem (that file was
        not properly removed from trn before calling ma_close())
      2f3779d3
    • Igor Babaev's avatar
      MDEV-16235 Server crashes in my_utf8_uni or in my_strtod_int · 6a04c2a1
      Igor Babaev authored
                 upon SELECT .. LIMIT 0
      
      The code must differentiate between a SELECT with contradictory
      WHERE/HAVING and one with LIMIT 0.
      Also for the latter printed 'Zero limit' instead of 'Impossible where'
      in the EXPLAIN output.
      6a04c2a1
  11. 19 May, 2018 2 commits
  12. 18 May, 2018 1 commit
  13. 17 May, 2018 1 commit
  14. 16 May, 2018 3 commits
  15. 15 May, 2018 2 commits
    • Monty's avatar
      MDEV-14943 Alter table ORDER BY bug · b050df4f
      Monty authored
      Problem was that if copy_data_between_tables() didn't do proper
      clean up in case of failures:
      - copy object was not properly freed
      - end_bulk_insert() was not called
      - mysql_trans_prepare_alter_copy_data() set THD->transaction.on to
        false which was not properly restored
      
      The last part caused a crash in Aria as Aria depends on that THD
      is correct.
      
      Other things:
      - Reset info->switched_transactional after usage (safety)
      - Reset bulk_insert_single_undo (safety)
      b050df4f
    • Monty's avatar
      MDEV-654 Assertion `share->now_transactional' failed in flush_log_for_bitmap... · 2b749a7b
      Monty authored
      MDEV-654 Assertion `share->now_transactional' failed in flush_log_for_bitmap on concurrent workload with Aria tables
      
      Problem was that we the bitmap needs to be flushed before disabling
      logging of redo entires, as writing the bitmap to disk by
      background checkpoint may cause redo entries.
      2b749a7b
  16. 11 May, 2018 2 commits
    • Sachin Agarwal's avatar
      Bug #26334149 - MYSQL CRASHES WHEN FULL TEXT INDEXES IBD FILES ARE ORPHANED DUE TO RENAME TABLE · 197bf0fe
      Sachin Agarwal authored
      Problem:
      When FTS index is added into a table which doesn't have 'FTS_DOC_ID'
      column, Innodb rebuilds table to add column 'FTS_DOC_ID'. when this FTS
      index is dropped from this table. Innodb doesn't not rebuild table to
      remove 'FTS_DOC_ID' column and deletes FTS index auxiliary tables.
      But it doesn't delete FTS common auxiliary tables.
      Later when the database having this table is renamed, FTS auxiliary
      tables are not renamed because table's flags2 (dict_table_t.flags2)
      has been resetted for DICT_TF2_FTS flag during FTS index drop operation.
      Now when we drop old database, it leads to an assert.
      
      Fix:
      During renaming of FTS auxiliary tables, ORed a condition to check if
      table has DICT_TF2_FTS_HAS_DOC_ID flag set.
      
      RB: 18769
      Reviewed by : Jimmy.Yang@oracle.com
      197bf0fe
    • Thirunarayanan Balathandayuthapani's avatar
      Bug #27041445 SERVER ABORTS IF FTS_DOC_ID EXCEEDS FTS_DOC_ID_MAX_STEP · 9c03ba8f
      Thirunarayanan Balathandayuthapani authored
      Problem:
      =======
      Multiple insert statement in table contains FULLTEXT KEY and a
      FTS_DOC_ID column aborts the server if the FTS_DOC_ID exceeds
      FTS_DOC_ID_MAX_STEP.
      
      Solution:
      ========
      Remove the exception for first committed insert statement.
      
      Reviewed-by: Jimmy Yang<jimmy.yang@oracle.com>
      RB: 18023
      9c03ba8f