1. 13 Dec, 2018 6 commits
  2. 12 Dec, 2018 9 commits
  3. 11 Dec, 2018 1 commit
  4. 10 Dec, 2018 1 commit
    • Marko Mäkelä's avatar
      MDEV-17938 ALTER TABLE reports ER_TABLESPACE_EXISTS after failed ALTER TABLE · 0d7cf06a
      Marko Mäkelä authored
      There was a race condition in the error handling of ALTER TABLE when
      the table contains FULLTEXT INDEX.
      
      During the error handling of an erroneous ALTER TABLE statement,
      when InnoDB would drop the internally created tables for FULLTEXT INDEX,
      it could happen that one of the hidden tables was being concurrently
      accessed by a background thread. Because of this, InnoDB would defer
      the drop operation to the background.
      
      However, related to MDEV-13564 backup-safe TRUNCATE TABLE and its
      prerequisite MDEV-14585, we had to make the background drop table queue
      crash-safe by renaming the table to a temporary name before enqueueing it.
      This renaming was introduced in a follow-up of the MDEV-13407 fix.
      As part of this rename operation, we were unnecessarily parsing the
      current SQL statement, because the same rename operation could also be
      executed as part of ALTER TABLE via ha_innobase::rename_table().
      
      If an ALTER TABLE statement was being refused due to incorrectly formed
      FOREIGN KEY constraint, then it could happen that the renaming of the hidden
      internal tables for FULLTEXT INDEX could also fail, triggering a host of
      error log messages, and causing a subsequent table-rebuilding ALTER TABLE
      operation to fail due to the tablespace already existing.
      
      innobase_rename_table(), row_rename_table_for_mysql(): Add the parameter
      use_fk for suppressing the parsing of FOREIGN KEY constraints. It
      will only be passed as use_fk=true by ha_innobase::rename_table(),
      which can be invoked as part of ALTER TABLE...ALGORITHM=COPY.
      0d7cf06a
  5. 07 Dec, 2018 7 commits
  6. 06 Dec, 2018 5 commits
  7. 05 Dec, 2018 1 commit
  8. 04 Dec, 2018 1 commit
  9. 03 Dec, 2018 1 commit
  10. 02 Dec, 2018 1 commit
  11. 01 Dec, 2018 1 commit
    • Igor Babaev's avatar
      MDEV-17871 Crash when running explain with CTE · 46960365
      Igor Babaev authored
      When the with clause of a query contains a recursive CTE that is not used
      then processing of EXPLAIN for this query does not require optimization
      of the unit specifying this CTE. In this case if 'derived' is the
      TABLE_LIST object created for this CTE then derived->derived_result is NULL
      and any assignment to derived->derived_result->table causes a crash.
      After fixing this problem in the code of st_select_lex_unit::prepare()
      EXPLAIN for such a query worked without crashes. Yet an execution
      plan for the recursive CTE appeared there. The cause of this problem was
      an incorrect condition used in JOIN::save_explain_data_intern() that
      determined whether CTE was to be optimized or not. A similar condition was
      used in select_describe() and this patch has corrected it as well.
      46960365
  12. 30 Nov, 2018 1 commit
  13. 29 Nov, 2018 5 commits