1. 19 Oct, 2018 2 commits
    • Sergey Vojtovich's avatar
      Remove unused code. · 64239419
      Sergey Vojtovich authored
      64239419
    • Sergey Vojtovich's avatar
      MDEV-14815 - Server crash or AddressSanitizer errors or valgrind warnings · 4ac85d6f
      Sergey Vojtovich authored
                   in thr_lock / has_old_lock upon FLUSH TABLES
      
      Explicit partition access of partitioned MEMORY table under LOCK TABLES
      may cause subsequent statements to crash the server, deadlock, trigger
      valgrind warnings or ASAN errors. Freed memory was being used due to
      incorrect cleanup.
      
      At least MyISAM and InnoDB don't seem to be affected, since their
      THR_LOCK structures don't survive FLUSH TABLES. MEMORY keeps table shared
      data (including THR_LOCK) even if there're no open instances.
      
      There's partition_info::lock_partitions bitmap, which holds bits of
      partitions allowed to be accessed after pruning. This bitmap is
      updated for each individual statement.
      
      This bitmap was abused in ha_partition::store_lock() such that when we
      need to unlock a table, locked by LOCK TABLES, only locks for partitions
      that were accessed by previous statement were released.
      
      Eventually FLUSH TABLES frees THR_LOCK_DATA objects, which are still
      linked into THR_LOCK lists. When such THR_LOCK gets reused we end up with
      freed memory access.
      
      Fixed by using ha_partition::m_locked_partitions bitmap similarly to
      ha_partition::external_lock().
      4ac85d6f
  2. 17 Oct, 2018 1 commit
  3. 16 Oct, 2018 3 commits
  4. 15 Oct, 2018 4 commits
  5. 13 Oct, 2018 1 commit
  6. 12 Oct, 2018 3 commits
  7. 09 Oct, 2018 1 commit
    • Vladislav Vaintroub's avatar
      MDEV-17413 Crash in my_malloc_size_cb_func() during shutdown with · 00ddc8bc
      Vladislav Vaintroub authored
      forceful connection close.
      
      Fix is to ensure that when close_connection() is called from shutdown
      thread, current_thd is set. This that allocation callback for THD specific
      memory won't assert(in debug version), or crash (in 10.1 and later)
      
      close_connection() allocates THD specific memory e.g when it writes
      the final error packet, and compression is ON for the connection.
      00ddc8bc
  8. 07 Oct, 2018 1 commit
    • Igor Babaev's avatar
      MDEV-17382 Hash join algorithm should not be used to join materialized · bd219043
      Igor Babaev authored
                 derived table / view by equality
      
      Now rows of a materialized derived table are always put into a
      temporary table before join operation. If BNLH is used to join this
      table with the result of a partial join then both operands of the
      join are actually put into main memory. In most cases this is not
      efficient.
      We could avoid this by sending the rows of the derived table directly
      to the join operation. However this kind of data flow is not supported
      yet.
      Fixed by not allowing usage of hash join algorithm to join a materialized
      derived table if it's joined by an equality predicate of the form
      f=e where f is a field of the derived table.
      bd219043
  9. 01 Oct, 2018 1 commit
  10. 22 Sep, 2018 2 commits
  11. 21 Sep, 2018 8 commits
  12. 20 Sep, 2018 3 commits
  13. 18 Sep, 2018 1 commit
    • Sergey Vojtovich's avatar
      MDEV-14410 - Assertion `table->pos_in_locked_tables == __null || · 327b2717
      Sergey Vojtovich authored
                   table->pos_in_locked_tables->table == table'
                   failed in mark_used_tables_as_free_for_reuse
      
      Assertion failure can be triggered by some DDL executed under LOCK TABLES
      that holds lock for DDL target table multiple times (either explicitly or
      implcitly).
      
      When closing all table instances for given table (e.g. when preparing for
      table removal during CREATE OR REPLACE), only one instance was removed
      from m_locked_tables list.
      
      Later we attempt to re-insert one of the instances in mysql_create_table()/
      add_back_last_deleted_lock(), which wasn't actually removed. This leads
      to m_locks_tables corruption, specifically loss of all following elements.
      
      Then UNLOCK TABLE won't reset some table instances properly (specifically
      pos_in_locked_tables), since they're not present in m_locked_tables.
      
      Eventually such table instance gets released to table cache and then
      re-used by subsequent statement, which triggers this assertion failure.
      327b2717
  14. 10 Sep, 2018 2 commits
  15. 06 Sep, 2018 2 commits
  16. 05 Sep, 2018 2 commits
  17. 04 Sep, 2018 3 commits
    • Sergei Golubchik's avatar
      09bc99fa
    • Sergei Golubchik's avatar
      MDEV-16465 Invalid (old?) table or database name or hang in... · d831cefb
      Sergei Golubchik authored
      MDEV-16465 Invalid (old?) table or database name or hang in ha_innobase::delete_table and log semaphore wait upon concurrent DDL with foreign keys
      
      Disable "Invalid (old?) table or database name" warning when
      converting table names in InnoDB's get_foreign_key_info().
      
      Because a name can be a temporary table name during the ALTER TABLE,
      and some other thread can do SHOW CREATE TABLE for the other table
      in the FK relationships _anytime_.
      d831cefb
    • Sergei Golubchik's avatar
      MDEV-16465 Invalid (old?) table or database name or hang in... · 9180e866
      Sergei Golubchik authored
      MDEV-16465 Invalid (old?) table or database name or hang in ha_innobase::delete_table and log semaphore wait upon concurrent DDL with foreign keys
      
      ALTER TABLE locks the table with TL_READ_NO_INSERT, to prevent the
      source table modifications while it's being copied. But there's an
      indirect way of modifying a table, via cascade FK actions.
      
      After previous commits, an attempt to modify an FK parent table
      will cause FK children to be prelocked, so the table-being-altered
      cannot be modified by a cascade FK action, because ALTER holds a
      lock and prelocking will wait.
      
      But if a new FK is being added by this very ALTER, then the target
      table is not locked yet (it's a temporary table). So, we have to
      lock FK parents explicitly.
      9180e866