1. 02 Nov, 2020 12 commits
    • Marko Mäkelä's avatar
      MDEV-21452: Replace os_event_t (except TTASEventMutex::m_event) · deb3992c
      Marko Mäkelä authored
      Let us replace os_event_t with mysql_cond_t, and replace the
      necessary ib_mutex_t with mysql_mutex_t so that they can be
      used with condition variables.
      
      The default ib_mutex_t implementation will use os_event_t.
      
      Also, replace polling (os_thread_sleep() or timed waits)
      with plain mysql_cond_wait() wherever possible.
      
      FIXME: Add test coverage of
      mariabackup --backup --kill-long-queries-timeout
      
      FIXME: innodb_fatal_semaphore_wait_threshold no longer works
      because it used to rely on lock_sys.mutex. The test could be
      rewritten to rely on an InnoDB rw_lock_t instead.
      
      fts_cache_t::lock: Replaced the rw_lock_t with a mutex.
      The only shared latch user was i_s_fts_index_cache_fill(),
      for producing content for the view
      INFORMATION_SCHEMA.INNODB_FT_INDEX_CACHED.
      
      fts_cache_t::init_lock: Replaced the rw_lock_t with a mutex.
      This was only being acquired in exclusive mode.
      deb3992c
    • Marko Mäkelä's avatar
      MDEV-21452: Replace os_event_t in rw_lock_t · 88722a7c
      Marko Mäkelä authored
      Let us use a single rw_lock_t::wait_mutex and two condition
      variables wait_cond, wait_cond_ex instead of two os_event_t
      (which wrap a mutex and condition variable and some other data)
      
      sync_array_wait_event(): Implement new waiting rules for rw_lock_t.
      FIXME: Sometimes, rw_lock_s_lock() hangs here. TODO: Find out
      what the lock->lock_word is in those cases. Maybe we should
      treat not only the value 0 but also X_LOCK_HALF_DECR specially.
      88722a7c
    • Marko Mäkelä's avatar
      Fix clang -Winconsistent-missing-override · 440d4b28
      Marko Mäkelä authored
      440d4b28
    • Vladislav Vaintroub's avatar
      Windows : require at least VS2019 for MSVC. · 504d4c1f
      Vladislav Vaintroub authored
      This will  avoid some errors on appveyor, due to outdated SDKs.
      504d4c1f
    • Nikita Malyavin's avatar
    • Nikita Malyavin's avatar
      MDEV-22506 Malformed error message for ER_KEY_CONTAINS_PERIOD_FIELDS · e618f7e9
      Nikita Malyavin authored
      Though this is an error message task, the problem was deep in the
      `mysql_prepare_create_table` implementation. The problem is described as
      follows:
      
      1. `append_system_key_parts` was called before
      `mysql_prepare_create_table`, though key name generation was done close to
      the latest stage of the latter.
      2. We can't move `append_system_key_parts` in the end, because system keys
      should be appended before some checks done.
      3. If the checks from `append_system_key_parts` are moved to the end of
      `mysql_prepare_create_table`, then some other inappropriate errors are
      issued. like `ER_DUP_FIELDNAME`.
      
      To have key name specified in error message, name generation should be done
      before the checks, which consequenced in more changes.
      
      The final design for key initialization in `mysql_prepare_create_table`
      follows. The initialization is done in three phases:
      1. Calculate a total number of keys created with respect to keys ignored.
       Allocate KEY* buffer.
      2. Generate unique names; calculate a total number of key parts.
       Make early checks. Allocate KEY_PART_INFO* buffer.
      3. Initialize key parts, make the rest of the checks.
      e618f7e9
    • Nikita Malyavin's avatar
      MDEV-22677 UPDATE crashes on partitioned HEAP table WITHOUT OVERLAPS · a79c6e36
      Nikita Malyavin authored
      `ha_heap::clone` was creating a handler by share's handlerton, which is
      partition handlerton.
      
      handler's handlerton should be used instead.
      
      Here in particular, HEAP handlerton will be used and it will create ha_heap
      handler.
      a79c6e36
    • Nikita Malyavin's avatar
      MDEV-22608 ASAN use-after-poison in TABLE::check_period_overlaps · d9e00770
      Nikita Malyavin authored
      The bug was fixed by MDEV-22599 bugfix, which changed `Field::cmp` call
      to `Field::cmp_prefix` in `TABLE::check_period_overlaps`.
      
      The trick is that `Field_bit::cmp` apparently calls `Field_bit::cmp_key`,
      which condiders an argument an actual pointer to data, which isn't correct
      for `Field_bit`, since it stores data by `bit_ptr`. which is in the
      beginning of the record, and using `ptr` is incorrect (we use it through
      `ptr_in_record` call)
      d9e00770
    • Nikita Malyavin's avatar
      MDEV-22639 Assertion failed in ha_check_overlaps upon multi-table update · afca9768
      Nikita Malyavin authored
      After Sergei's cleanup this assertion is not actual anymore -- we can't
      predict if the handler was used for lookup, especially in multi-update
      scenario.
      
      `position(old_data)` is made earlier in `ha_check_overlaps`, therefore it
      is guaranteed that we compare right refs.
      afca9768
    • Nikita Malyavin's avatar
      MDEV-22714 Assertion failed upon multi-update on table WITHOUT OVERLAPS · d543363f
      Nikita Malyavin authored
      The problem here was that ha_check_overlaps internally uses ha_index_read,
      which in case of fail overwrites table->status. Even though the handlers
      are different, they share a common table, so the value is anyway spoiled.
      This is bad, and table->status is badly designed and overweighted by
      functionality, but nothing can be done with it, since the code related to
      this logic is ancient and it's impossible to extract it with normal effort.
      
      So let's just save and restore the value in ha_update_row before and after
      the checks.
      
      Other operations like INSERT and simple UPDATE are not in risk, since they
      don't use this table->status approach.
      DELETE does not do any unique checks, so it's also safe.
      d543363f
    • Nikita Malyavin's avatar
      Add DBUG_ASSERT in Field::ptr_in_record · 30894fe9
      Nikita Malyavin authored
      1. Subtracting table->record[0] from record is UB (non-contiguous buffers)
      2. It is very popular to use move_field_offset, which changes Field::ptr,
      but leaves table->record[0] unchanged. This makes a ptr_in_record result
      incorrect, since it relies on table->record[0] value.
      The check ensures the result is within the queried record boundaries.
      30894fe9
    • Elena Stepanova's avatar
      95fcd567
  2. 01 Nov, 2020 1 commit
  3. 31 Oct, 2020 1 commit
  4. 30 Oct, 2020 16 commits
  5. 29 Oct, 2020 10 commits