1. 18 Oct, 2018 8 commits
  2. 17 Oct, 2018 8 commits
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · f454189c
      Marko Mäkelä authored
      f454189c
    • Marko Mäkelä's avatar
      Merge 10.3 into 10.4 · d88c136b
      Marko Mäkelä authored
      d88c136b
    • Marko Mäkelä's avatar
      MDEV-17483 Insert on delete-marked record can wrongly inherit old values for instantly added column · 2fa4ed03
      Marko Mäkelä authored
      row_ins_clust_index_entry_low(): Do not call dtuple_t::trim()
      before row_ins_clust_index_entry_by_modify(), so that the values
      of all columns will be available in row_upd_build_difference_binary().
      If applicable, the tuple can be trimmed in btr_cur_optimistic_update()
      or btr_cur_pessimistic_update(), which will be called by
      row_ins_clust_index_entry_by_modify().
      2fa4ed03
    • Marko Mäkelä's avatar
      MDEV-13564: Set innodb_safe_truncate=ON by default · 853a0a43
      Marko Mäkelä authored
      The setting innodb_safe_truncate=ON reduces compatibility with older
      versions of MariaDB and backup tools in two ways.
      
      First, we will be writing TRX_UNDO_RENAME_TABLE records, which older
      versions do not know about. These records could be misinterpreted if
      a DDL transaction was recovered and would be rolled back.
      Such rollback is only possible if the server was killed while
      an incomplete DDL transaction was persisted. On transaction completion,
      the insert_undo log pages would only be repurposed for new undo log
      allocations, and their contents would not matter. So, older versions
      will not have a problem with innodb_safe_truncate=ON if the server was
      shut down cleanly.
      
      Second, to prevent such recovery failure, innodb_safe_truncate=ON will
      cause a modification of the redo log format identifier, which will
      prevent older versions from starting up after a crash. MariaDB Server
      versions older than 10.2.13 will refuse to start up altogether, even
      after clean shutdown.
      
      A server restart with innodb_safe_truncate=OFF will restore compatibility
      with older server and backup versions.
      853a0a43
    • Igor Babaev's avatar
      MDEV-17419 Subquery with group by returns wrong results · c2c1550f
      Igor Babaev authored
      Added only test case because the bug was fixed by the patch for mdev-17382.
      c2c1550f
    • Igor Babaev's avatar
      MDEV-17107 Assertion `table_list->table' failed in find_field_in_table_ref · dc3f5594
      Igor Babaev authored
      Added only test case because the bug was fixed by the patch for mdev-16992.
      dc3f5594
    • Igor Babaev's avatar
      MDEV-17027 server crashes in Bitmap<64u>::merge · 13e217b8
      Igor Babaev authored
      The function and_new_conditions_to_optimized_cond() incorrectly handled
      the WHERE conditions with one multiple equality and one IN subquery predicate
      that could be converted into a jtbm semi-join. This could cause crashes.
      
      The fix code was prepared by Galina Shalygina.
      13e217b8
    • Alexander Barkov's avatar
  3. 16 Oct, 2018 6 commits
  4. 15 Oct, 2018 1 commit
  5. 14 Oct, 2018 3 commits
    • Igor Babaev's avatar
      MDEV-17222 Reproducible server crash in String_list::append_str or · 103b1df5
      Igor Babaev authored
                 in Field_iterator_table::create_item
      
      When IN predicate is converted to IN subquery we have to ensure that
      any item from the select list of the subquery has some name and this name
      is unique across the select list.
      This was not guaranteed by the code before the patch for MDEV-17222.
      If the name of an item of the select list was not set, and this happened
      for binary constants, then the server crashed. If the first row in the IN
      list contained the same constant in two different positions then the server
      returned an error message.
      This was fixed by providing all constants in the first row of the IN list
      with generated names.
      103b1df5
    • Varun Gupta's avatar
      MDEV-16990:server crashes in base_list_iterator::next · af6077b5
      Varun Gupta authored
      When we have a query which has implicit_grouping then we are sure that we would end up with only one
      row so there is no point to do DISTINCT computation
      af6077b5
    • Alexander Barkov's avatar
  6. 13 Oct, 2018 4 commits
  7. 12 Oct, 2018 5 commits
  8. 11 Oct, 2018 5 commits
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 7e869a27
      Marko Mäkelä authored
      7e869a27
    • Marko Mäkelä's avatar
      MDEV-17433 Allow InnoDB start up with empty ib_logfile0 from mariabackup --prepare · 81a5b6cc
      Marko Mäkelä authored
      A prepared backup from Mariabackup does not really need to contain any
      redo log file, because all log will have been applied to the data files.
      
      When the user copies a prepared backup to a data directory (overwriting
      existing files), it could happen that the data directory already contained
      redo log files from the past. mariabackup --copy-back) would delete the
      old redo log files, but a user’s own copying script might not do that.
      To prevent corruption caused by mixing an old redo log file with data
      files from a backup, starting with MDEV-13311, Mariabackup would create
      a zero-length ib_logfile0 that would prevent startup.
      
      Actually, there is no need to prevent InnoDB from starting up when a
      single zero-length file ib_logfile0 is present. Only if there exist
      multiple data files of different lengths, then we should refuse to
      start up due to inconsistency. A single zero-length ib_logfile0 should
      be treated as if the log files were missing: create new log files
      according to the configuration.
      
      open_log_file(): Remove. There is no need to open the log files
      at this point, because os_file_get_status() already determined
      the size of the file.
      
      innobase_start_or_create_for_mysql(): Move the creation of new
      log files a little later, not when finding out that the first log
      file does not exist, but after finding out that it does not exist
      or it exists as a zero-length file.
      81a5b6cc
    • Eugene Kosov's avatar
      be31c18e
    • Marko Mäkelä's avatar
      Fix a sign mismatch · b8944e89
      Marko Mäkelä authored
      b8944e89
    • Marko Mäkelä's avatar
      MDEV-13564: Replace innodb_unsafe_truncate with innodb_safe_truncate · 6319c0b5
      Marko Mäkelä authored
      Rename the 10.2-specific configuration option innodb_unsafe_truncate
      to innodb_safe_truncate, and invert its value.
      
      The default (for now) is innodb_safe_truncate=OFF, to avoid
      disrupting users with an undo and redo log format change within
      a Generally Available (GA) release series.
      6319c0b5