1. 31 Aug, 2018 2 commits
    • Marko Mäkelä's avatar
      MDEV-16647 InnoDB fails to drop large temporary table on disconnect · f693170c
      Marko Mäkelä authored
      This regression was introduced in MDEV-16515.
      We would fail to drop a temporary table on client disconnect,
      because trx_is_interrupted() would hold. To add insult to
      injury, in MariaDB 10.1, InnoDB temporary tables are actually
      persistent, so the garbage temporary tables will never be dropped.
      
      row_drop_table_for_mysql(): If several iterations of
      buf_LRU_drop_page_hash_for_tablespace() are needed,
      do not interrupt dropping a temporary table even after
      the transaction was marked as killed.
      
      Server shutdown will still terminate the loop, and also DROP TABLE
      of persistent tables will keep checking if the execution was aborted.
      f693170c
    • Marko Mäkelä's avatar
      Revert MDEV-9519 due to regressions · 3b5d3cd6
      Marko Mäkelä authored
      This reverts commit 75dfd4ac.
      3b5d3cd6
  2. 30 Aug, 2018 2 commits
  3. 29 Aug, 2018 1 commit
  4. 28 Aug, 2018 2 commits
  5. 27 Aug, 2018 1 commit
    • Monty's avatar
      MDEV-15797 Assertion `thd->killed != 0' failed in ha_maria::enable_indexes · cded083a
      Monty authored
      Problem was that a parallel open of a table, overwrote info->state that
      was in used by repair.
      
      Fixed by changing _ma_tmp_disable_logging_for_table() to use
      a new state buffer state.no_logging to store the temporary state.
      
      Other things:
      - Use original number of rows when retrying repair to get rid of a
        potential warning "Number of rows changed from X to Y"
      - Changed maria_commit() to make it easier to merge with 10.4
      - If table is not locked (like with show commands), use the global
        number of rows as the local number may not be up to date.
        (Minor not critical fix)
      - Added some missing DBUG_RETURN
      cded083a
  6. 21 Aug, 2018 4 commits
  7. 17 Aug, 2018 1 commit
  8. 15 Aug, 2018 5 commits
    • Oleksandr Byelkin's avatar
      Merge branch '5.5' into 10.0 · bcc677bb
      Oleksandr Byelkin authored
      bcc677bb
    • Sergei Petrunia's avatar
      MDEV-6439: Server crashes in Explain_union::print_explain with explain in slow log, tis620 charset · b62ac161
      Sergei Petrunia authored
      Item_subselect::is_expensive() used to return FALSE (Inexpensive) whenever
      it saw that one of SELECTs in the Subquery's UNION is degenerate. It
      ignored the fact that other parts of the UNION might not be inexpensive,
      including the case where pther parts of the UNION have no query plan yet.
      
      For a subquery in form col >= ANY (SELECT 'foo' UNION SELECT 'bar')
      this would cause the query to be considered inexpensive when there is
      no query plan for the second part of the UNION, which in turn would
      cause the SELECT 'foo' to compute and free itself while still inside
      JOIN::optimize for that SELECT (See MDEV comment for full description).
      b62ac161
    • Oleksandr Byelkin's avatar
      MDEV-15475: Assertion `!table || (!table->read_set ||... · 1b797e9e
      Oleksandr Byelkin authored
      MDEV-15475: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed on EXPLAIN EXTENDED with constant table and view
      
      Print constant ISNULL value independent.
      Fix of printing of view FRM and CREATE VIEW output
      1b797e9e
    • Julius Goryavsky's avatar
      This is patch for the https://jira.mariadb.org/browse/MDEV-9519 issue: · 75dfd4ac
      Julius Goryavsky authored
      If we have a 2+ node cluster which is replicating from an async master
      and the binlog_format is set to STATEMENT and multi-row inserts are executed
      on a table with an auto_increment column such that values are automatically
      generated by MySQL, then the server node generates wrong auto_increment
      values, which are different from what was generated on the async master.
      
      The causes and fixes:
      
      1. We need to improve processing of changing the auto-increment values
      after changing the cluster size.
      
      2. If wsrep auto_increment_control switched on during operation of
      the node, then we should immediately update the auto_increment_increment
      and auto_increment_offset global variables, without waiting of the next
      invocation of the wsrep_view_handler_cb() callback. In the current version
      these variables retain its initial values if wsrep_auto_increment_control
      is switched on during operation of the node, which leads to inconsistent
      results on the different nodes in some scenarios.
      
      3. If wsrep auto_increment_control switched off during operation of the node,
      then we must return the original values of the auto_increment_increment and
      auto_increment_offset global variables, as the user has set. To make this
      possible, we need to add a "shadow copies" of these variables (which stores
      the latest values set by the user).
      75dfd4ac
    • Jan Lindström's avatar
      Merge pull request #844 from codership/10.1-MDEV-15933 · 59608156
      Jan Lindström authored
      MDEV-15933 Cannot resume Node SYNCED state when wsrep_desync is done after FTWRL
      59608156
  9. 14 Aug, 2018 2 commits
  10. 13 Aug, 2018 2 commits
  11. 11 Aug, 2018 1 commit
  12. 09 Aug, 2018 2 commits
  13. 08 Aug, 2018 1 commit
  14. 07 Aug, 2018 2 commits
  15. 06 Aug, 2018 2 commits
  16. 05 Aug, 2018 3 commits
  17. 04 Aug, 2018 2 commits
  18. 03 Aug, 2018 5 commits