1. 10 Aug, 2020 3 commits
  2. 06 Aug, 2020 3 commits
  3. 05 Aug, 2020 1 commit
  4. 04 Aug, 2020 3 commits
    • Sergei Golubchik's avatar
      a09a06d5
    • Sergei Golubchik's avatar
      5.6.49-89.0 · 2adaaeba
      Sergei Golubchik authored
      2adaaeba
    • Sachin's avatar
      MDEV-23089 rpl_parallel2 fails in 10.5 · e3c18b8e
      Sachin authored
      Problem:- rpl_parallel2 was failing non-deterministically
      Analysis:-
      When FLUSH TABLES WITH READ LOCK is executed, it will allow all worker
      threads to complete their ongoing transactions and then it will pause them.
      At this state FTWRL will proceed to acquire global read lock. FTWRL first
      blocks threads from starting new commits, then upgrades the lock to block
      commit of existing transactions.
        Step1:
          FLUSH TABLES WITH READ LOCK - Blocks new commits
        Step2:
          * STOP SLAVE command enables 'force_abort=1' which unblocks workers,
            they continue to execute events.
          * T1: Waits in 'record_gtid' call to update 'gtid_slave_pos' table with
            its current GTID, but it is blocked becuase of Step1.
          * T2: Holds COMMIT lock and waits for T1 to commit.
        Step3:
          FLUSH TABLES WITH READ LOCK - Waiting to get BLOCK_COMMIT.
      This results in deadlock. When STOP SLAVE command allows paused workers to
      proceed, workers should skip the execution of all further events, similar
      to 'conservative' parallel mode.
      Solution:-
      We will assign 1 to skip_event_group when we are aborted in do_ftwrl_wait.
      rpl_parallel_entry->pause_sub_id is only reset when force_abort is off in
      rpl_pause_after_ftwrl.
      e3c18b8e
  5. 03 Aug, 2020 2 commits
  6. 02 Aug, 2020 2 commits
  7. 30 Jul, 2020 3 commits
  8. 29 Jul, 2020 7 commits
  9. 28 Jul, 2020 1 commit
    • Karthik Kamath's avatar
      MDEV-15961: Fix stacktraces under FreeBSD (aarch64) · e6cb263e
      Karthik Kamath authored
      Largely based on MySQL commit
      https://github.com/mysql/mysql-server/commit/75271e51d60bce8683423b208cbb43b11ca6060e
      
      MySQL Ref:
          BUG#24566529: BACKPORT BUG#23575445 TO 5.6
      
          (cut)
          Also, the PTR_SANE macro which tries to check if a pointer
          is invalid (used when printing pointer values in stack traces)
          gave false negatives on OSX/FreeBSD. On these platforms we
          now simply check if the pointer is non-null. This also removes
          a sbrk() deprecation warning when building on OS X. (It was
          before only disabled with building using XCode).
      
      Removed execinfo path of MySQL patch that was already included.
      
      sbrk doesn't exist on FreeBSD aarch64.
      
      Removed HAVE_BSS_START based detection and replaced with __linux__
      as it doesn't exist on OSX, Solaris or Windows.  __bss_start
      exists on mutiple Linux architectures.
      
      Tested on FreeBSD and Linux x86_64. Being in FreeBSD ports for 2
      years implies a good testing there on all FreeBSD architectures there
      too. MySQL-8.0.21 code is functionally identical to original commit.
      e6cb263e
  10. 27 Jul, 2020 5 commits
  11. 25 Jul, 2020 1 commit
  12. 24 Jul, 2020 3 commits
    • Sergei Petrunia's avatar
      MDEV-23221: A subquery causes crash · b000d695
      Sergei Petrunia authored
      * Fix the crash: IN-to-EXISTS rewrite causes an error (and so
        JOIN::optimize() fails with an error, too), don't call
        update_used_tables(). Terminate the query execution instead.
      
      * Fix the cause of the error in the IN-to-EXISTS rewrite: don't do
        the rewrite if doing it will cause an error of this kind:
        This version of MariaDB doesn't yet support 'SUBQUERY in ROW in left
        expression of IN/ALL/ANY'
      
      * Fix another issue exposed by this testcase:
        JOIN::setup_subquery_caches() may be invoked before any select has
        saved its query plan, and will crash because none of the SELECTs
        has called create_explain_query_if_not_exists() to create the Explain
        Data Structure for this SELECT.
      
      TODO: When merging this to 10.2, remove the poorly-placed call to
      create_explain_query_if_not_exists made by fix for M_D_E_V-16153
      b000d695
    • Daniel Black's avatar
      mysql_install_db: help lists --defaults-file twice · 4b97f14a
      Daniel Black authored
      Removed duplicate.
      
      Also move the --no-defaults option close to the other "default*"
      options.
      4b97f14a
    • Teemu Ollakka's avatar
      MDEV-23272 Galera stack-use-after-scope error with ASAN build · 8ef41c60
      Teemu Ollakka authored
      THD proc info was assigned from stack allocated temporary buffer
      which went out of scope immediately after assignment.
      
      Fixed by removing the use of temp buffer and assign proc info
      from string literal.
      8ef41c60
  13. 23 Jul, 2020 3 commits
  14. 22 Jul, 2020 2 commits
    • Ian Gilfillan's avatar
      Code comment spellfixes · d2982331
      Ian Gilfillan authored
      d2982331
    • Varun Gupta's avatar
      MDEV-19232: Floating point precision / value comparison problem · 62d73df6
      Varun Gupta authored
      The issue occurs when the subquery_cache is enabled.
      When there is a cache miss the division was leading to a value with scale 9.
      In the case of cache hit the value returned was of scale 9 and due to the different
      values for the scales the where condition evaluated to FALSE, hence the output
      was incomplete.
      
      To fix this problem we need to round up the decimal to the limit mentioned in
      Item::decimals. This would make sure the values are compared with the same
      scale.
      62d73df6
  15. 20 Jul, 2020 1 commit
    • Marko Mäkelä's avatar
      MDEV-23190 InnoDB data file extension is not crash-safe · 57ec42bc
      Marko Mäkelä authored
      When InnoDB is extending a data file, it is updating the FSP_SIZE
      field in the first page of the data file.
      
      In commit 8451e090 (MDEV-11556)
      we removed a work-around for this bug and made recovery stricter,
      by making it track changes to FSP_SIZE via redo log records, and
      extend the data files before any changes are being applied to them.
      
      It turns out that the function fsp_fill_free_list() is not crash-safe
      with respect to this when it is initializing the change buffer bitmap
      page (page 1, or generally, N*innodb_page_size+1). It uses a separate
      mini-transaction that is committed (and will be written to the redo
      log file) before the mini-transaction that actually extended the data
      file. Hence, recovery can observe a reference to a page that is
      beyond the current end of the data file.
      
      fsp_fill_free_list(): Initialize the change buffer bitmap page in
      the same mini-transaction.
      
      The rest of the changes are fixing a bug that the use of the separate
      mini-transaction was attempting to work around. Namely, we must ensure
      that no other thread will access the change buffer bitmap page before
      our mini-transaction has been committed and all page latches have been
      released.
      
      That is, for read-ahead as well as neighbour flushing, we must avoid
      accessing pages that might not yet be durably part of the tablespace.
      
      fil_space_t::committed_size: The size of the tablespace
      as persisted by mtr_commit().
      
      fil_space_t::max_page_number_for_io(): Limit the highest page
      number for I/O batches to committed_size.
      
      MTR_MEMO_SPACE_X_LOCK: Replaces MTR_MEMO_X_LOCK for fil_space_t::latch.
      
      mtr_x_space_lock(): Replaces mtr_x_lock() for fil_space_t::latch.
      
      mtr_memo_slot_release_func(): When releasing MTR_MEMO_SPACE_X_LOCK,
      copy space->size to space->committed_size. In this way, read-ahead
      or flushing will never be invoked on pages that do not yet exist
      according to FSP_SIZE.
      57ec42bc