1. 05 Oct, 2020 4 commits
  2. 06 Aug, 2020 3 commits
  3. 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
  4. 03 Aug, 2020 6 commits
  5. 02 Aug, 2020 8 commits
  6. 01 Aug, 2020 4 commits
    • Marko Mäkelä's avatar
      MDEV-21201: Null-Merge 10.3 · 297746de
      Marko Mäkelä authored
      Sorry, this should have been pushed instead of
      7f4c749d to 10.3.
      (The push of d63631c3
      prevented required an extra merge of that fix.
      And that commit was merged to 10.4
      da78e952.)
      297746de
    • Marko Mäkelä's avatar
      MDEV-21201: Add --sorted_result to the test, for 10.4 · 7f4c749d
      Marko Mäkelä authored
      On MariaDB 10.4 (commit 4db4b773),
      the query results would not be sorted, which creates random result
      differences. Let us explicitly sort the results already in 10.3
      in order to avoid future merge trouble.
      7f4c749d
    • Marko Mäkelä's avatar
      MDEV-21201: Add --sorted_result to the test, for 10.4 · 976abe64
      Marko Mäkelä authored
      On MariaDB 10.4 (commit 4db4b773),
      the query results would not be sorted, which creates random result
      differences. Let us explicitly sort the results already in 10.3
      in order to avoid future merge trouble.
      976abe64
    • Alexander Barkov's avatar
      MDEV-19632 Replication aborts with ER_SLAVE_CONVERSION_FAILED upon CREATE ... SELECT in ORACLE mode · d63631c3
      Alexander Barkov authored
      - Adding optional qualifiers to data types:
          CREATE TABLE t1 (a schema.DATE);
        Qualifiers now work only for three pre-defined schemas:
      
          mariadb_schema
          oracle_schema
          maxdb_schema
      
        These schemas are virtual (hard-coded) for now, but may turn into real
        databases on disk in the future.
      
      - mariadb_schema.TYPE now always resolves to a true MariaDB data
        type TYPE without sql_mode specific translations.
      
      - oracle_schema.DATE translates to MariaDB DATETIME.
      
      - maxdb_schema.TIMESTAMP translates to MariaDB DATETIME.
      
      - Fixing SHOW CREATE TABLE to use a qualifier for a data type TYPE
        if the current sql_mode translates TYPE to something else.
      
      The above changes fix the reported problem, so this script:
      
          SET sql_mode=ORACLE;
          CREATE TABLE t2 AS SELECT mariadb_date_column FROM t1;
      
      is now replicated as:
      
          SET sql_mode=ORACLE;
          CREATE TABLE t2 (mariadb_date_column mariadb_schema.DATE);
      
      and the slave can unambiguously treat DATE as the true MariaDB DATE
      without ORACLE specific translation to DATETIME.
      
      Similar,
      
          SET sql_mode=MAXDB;
          CREATE TABLE t2 AS SELECT mariadb_timestamp_column FROM t1;
      
      is now replicated as:
      
          SET sql_mode=MAXDB;
          CREATE TABLE t2 (mariadb_timestamp_column mariadb_schema.TIMESTAMP);
      
      so the slave treats TIMESTAMP as the true MariaDB TIMESTAMP
      without MAXDB specific translation to DATETIME.
      d63631c3
  7. 31 Jul, 2020 10 commits
    • Oleksandr Byelkin's avatar
      MDEV-21201 No records produced in information_schema query, depending on projection · a8458a23
      Oleksandr Byelkin authored
      In case of NATURAL JOIN / USING mark all field (one table can not be opened
      in any case so optimisation does not worth it).
      
      IMHO table should be checked for used fields and filled after prepare,
      when we will fave whole info about used fields but it is too big change
      for a bugfix. Which will be made later by Serg patch
      a8458a23
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 78c2a5ab
      Marko Mäkelä authored
      78c2a5ab
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-14711 Fix-up · 5ec40fbb
      Thirunarayanan Balathandayuthapani authored
      5ec40fbb
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 8bb2170d
      Marko Mäkelä authored
      8bb2170d
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 66ec3a77
      Marko Mäkelä authored
      66ec3a77
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-22511 innodb.truncate_foreign failed in buildbot with wrong error code · a6066e23
      Thirunarayanan Balathandayuthapani authored
      - Adding lock_wait_timeout value as 1 make sure that truncate table
      fails instead of making MDL timeout.
      a6066e23
    • Marko Mäkelä's avatar
      MDEV-11799 Doublewrite recovery can corrupt data pages · 879ba197
      Marko Mäkelä authored
      The purpose of the InnoDB doublewrite buffer is to make InnoDB
      tolerant against cases where the server was killed in the middle
      of a page write. (In Linux, killing a process may interrupt a
      write system call, typically on a 4096-byte boundary.)
      
      There may exist multiple copies of a page number in the doublewrite
      buffer. Recovery should choose the latest valid copy of the page.
      By design, the FIL_PAGE_LSN must not precede the latest checkpoint LSN
      nor be later than the end of the recovered log.
      
      For page_compressed and encrypted pages, we were missing proper
      consistency checks. In the 10.4 data set generated for in MDEV-23231,
      the data file contained a valid page_compressed page, and an
      identical copy of that page was also present in the doublewrite
      buffer. But, recovery would incorrectly consider the page invalid
      and restore an uncompressed copy of the same page that had been
      written before the log checkpoint. (In fact, no redo log was to
      be applied to that page.)
      
      buf_dblwr_process(): Validate the FIL_PAGE_LSN in the doublewrite
      buffer pages, and always skip page 0, because those pages should
      have been recovered by Datafile::restore_from_doublewrite() if
      necessary.
      
      Datafile::restore_from_doublewrite(): Choose the latest applicable
      page from the doublewrite buffer.
      
      recv_dblwr_t::find_page(): Also validate encrypted or
      page_compressed pages.
      
      recv_dblwr_t::validate_page(): New function to validate a page,
      either a copy in a data file or in the doublewrite buffer.
      Also validate encrypted or page_compressed pages.
      
      This is joint work with Thirunarayanan Balathandayuthapani.
      879ba197
    • Marko Mäkelä's avatar
      MDEV-23198 Crash in REPLACE · f35d1721
      Marko Mäkelä authored
      row_vers_impl_x_locked_low(): clust_offsets may point to memory
      that is allocated by mem_heap_alloc() and may have been freed.
      For initializing clust_offsets, try to use the stack-allocated
      buffer instead of a pointer that may point to freed memory.
      
      This fixes a regression that was introduced in
      commit f0aa073f (MDEV-20950).
      f35d1721
    • Nikita Malyavin's avatar
      MDEV-18042 Server crashes upon adding a non-null date column under... · fd0abc89
      Nikita Malyavin authored
      MDEV-18042 Server crashes upon adding a non-null date column under NO_ZERO_DATE with ALGORITHM=INPLACE
      
      accept table_name and db_name instead of table_share in make_truncated_value_warning
      fd0abc89
    • Nikita Malyavin's avatar
      MDEV-19338 InnoDB: Failing assertion: !cursor->index->is_committed() · 91ebf184
      Nikita Malyavin authored
      Call mark_columns_per_binlog_row_image before find_row() to set up table->vcol_set early,
      so the virtual column value will be updated after record read (ha_rnd_pos/ha_index_next/etc)
      by table->update_virtual_fields() call
      91ebf184
  8. 30 Jul, 2020 2 commits