1. 22 Mar, 2019 3 commits
  2. 21 Mar, 2019 10 commits
  3. 20 Mar, 2019 2 commits
    • Marko Mäkelä's avatar
      MDEV-18981 Possible corruption when using FOREIGN KEY with virtual columns · 630199e7
      Marko Mäkelä authored
      row_ins_foreign_fill_virtual(): Construct update->old_vrow
      with ROW_COPY_DATA instead of ROW_COPY_POINTERS. With the latter,
      the object would be pointing to a buffer pool page frame. That page
      frame can become stale and invalid as soon as
      row_ins_foreign_check_on_constraint() invokes mtr_t::commit().
      
      Most of the time, the pointer target is not going to be overwritten
      by anything, and everything appears to work correctly.
      Buffer pool page replacement is highly unlikely, and any pessimistic
      operation that would overwrite the old location of the record is only
      slightly more likely. It is not known whether there is an actual bug.
      This came up while diagnosing MDEV-18879 in MariaDB 10.3.
      630199e7
    • Alexander Barkov's avatar
      Fixing "mtr func_math" failure in the test for MDEV-17643 · ef81d2ea
      Alexander Barkov authored
      Adding an intermediate volatile variable to avoid using co-processor registers
      on some platforms (e.g. 32-bit x86).
      This change makes test results stable accross all platforms.
      ef81d2ea
  4. 19 Mar, 2019 3 commits
    • Marko Mäkelä's avatar
      MDEV-18084: Crash on UPDATE after upgrade from 10.0 or 10.1 · a77e2668
      Marko Mäkelä authored
      MariaDB Server 10.0 and 10.1 support non-indexed virtual columns,
      which are hidden from the storage engine. Starting with MDEV-5800
      in MariaDB 10.2.2, the virtual columns are visible to storage engines.
      
      calc_row_difference(): Follow up the MDEV-17199 fix, which forgot
      to increment num_v when skipping virtual columns in tables that
      were created before MariaDB 10.2.2. This caused a corruption of
      the update vector when an updated persistent column is preceded
      by virtual columns.
      a77e2668
    • Marko Mäkelä's avatar
      Replace innobase_is_v_fld() with Field::stored_in_db() · 1efda582
      Marko Mäkelä authored
      The macro innobase_is_v_fld() turns out to be equivalent with
      the opposite of Field::stored_in_db(). Remove the macro and
      invoke the member function directly.
      
      innodb_base_col_setup_for_stored(): Simplify a condition to only
      check Field::vcol_info.
      
      innobase_create_index_def(): Replace some redundant code with
      DBUG_ASSERT().
      1efda582
    • Marko Mäkelä's avatar
      MDEV-18960: Assertion !omits_virtual_cols(*form->s) on TRUNCATE · 9471dbaf
      Marko Mäkelä authored
      MariaDB before MDEV-5800 in version 10.2.2 did not support
      indexed virtual columns. Non-persistent virtual columns were
      hidden from storage engines. Only starting with MDEV-5800, InnoDB
      would create internal metadata on virtual columns.
      
      On TRUNCATE TABLE, an old .frm file from before MDEV-5800 may be
      used as the table schema. When the table is being re-created by
      InnoDB, the old schema must be used. That is, we may hide
      the existence of virtual columns from InnoDB.
      
      create_table_check_doc_id_col(): Remove the assertion that failed.
      This function can actually correctly deal with virtual columns
      that could have been created before MariaDB 10.2.2 introduced MDEV-5800.
      
      create_table_info_t::create_table_def(): Do not create metadata for
      virtual columns if the table definition was created before MariaDB 10.2.2.
      9471dbaf
  5. 18 Mar, 2019 5 commits
    • Alexander Barkov's avatar
    • Marko Mäkelä's avatar
      MDEV-17482 InnoDB fails to say which fatal error fsync() returned · 00572a0b
      Marko Mäkelä authored
      os_file_fsync_posix(): If fsync() returns a fatal error,
      do include errno in the error message.
      
      In the future, we might handle fsync() or write or allocation failures
      on InnoDB data files a little more gracefully: flag the affected index
      or table as corrupted, and deny any subsequent writes to the table.
      
      If a write to the undo log or redo log fails, an alternative to
      killing the server could be to deny any writes to InnoDB tables
      until the server has been restarted.
      00572a0b
    • Marko Mäkelä's avatar
      1d728a98
    • Marko Mäkelä's avatar
      Post-merge fix after 0508d327 · e3618a33
      Marko Mäkelä authored
      e3618a33
    • sysprg's avatar
      MDEV-17262: mysql crashed on galera while node rejoined cluster (#895) · 26432e49
      sysprg authored
      This patch contains a fix for the MDEV-17262/17243 issues and
      new mtr test.
      
      These issues (MDEV-17262/17243) have two reasons:
      
      1) After an intermediate commit, a transaction loses its status
      of "transaction that registered in the MySQL for 2pc coordinator"
      (in the InnoDB) due to the fact that since version 10.2 the
      write_row() function (which located in the ha_innodb.cc) does
      not call trx_register_for_2pc(m_prebuilt->trx) during the processing
      of split transactions. It is necessary to restore this call inside
      the write_row() when an intermediate commit was made (for a split
      transaction).
      
      Similarly, we need to set the flag of the started transaction
      (m_prebuilt->sql_stat_start) after intermediate commit.
      
      The table->file->extra(HA_EXTRA_FAKE_START_STMT) called from the
      wsrep_load_data_split() function (which located in sql_load.cc)
      will also do this, but it will be too late. As a result, the call
      to the wsrep_append_keys() function from the InnoDB engine may be
      lost or function may be called with invalid transaction identifier.
      
      2) If a transaction with the LOAD DATA statement is divided into
      logical mini-transactions (of the 10K rows) and binlog is rotated,
      then in rare cases due to the wsrep handler re-registration at the
      boundary of the split, the last portion of data may be lost. Since
      splitting of the LOAD DATA into mini-transactions is technical,
      I believe that we should not allow these mini-transactions to fall
      into separate binlogs. Therefore, it is necessary to prohibit the
      rotation of binlog in the middle of processing LOAD DATA statement.
      
      https://jira.mariadb.org/browse/MDEV-17262 and
      https://jira.mariadb.org/browse/MDEV-17243
      26432e49
  6. 16 Mar, 2019 2 commits
  7. 15 Mar, 2019 10 commits
  8. 14 Mar, 2019 5 commits
    • Sergei Golubchik's avatar
      fix gcc 8 compiler warnings · 3d2d060b
      Sergei Golubchik authored
      There were two newly enabled warnings:
      1. cast for a function pointers. Affected sql_analyse.h, mi_write.c
         and ma_write.cc, mf_iocache-t.cc, mysqlbinlog.cc, encryption.cc, etc
      
      2. memcpy/memset of nontrivial structures. Fixed as:
      * the warning disabled for InnoDB
      * TABLE, TABLE_SHARE, and TABLE_LIST got a new method reset() which
        does the bzero(), which is safe for these classes, but any other
        bzero() will still cause a warning
      * Table_scope_and_contents_source_st uses `TABLE_LIST *` (trivial)
        instead of `SQL_I_List<TABLE_LIST>` (not trivial) so it's safe to
        bzero now.
      * added casts in debug_sync.cc and sql_select.cc (for JOIN)
      * move assignment method for MDL_request instead of memcpy()
      * PARTIAL_INDEX_INTERSECT_INFO::init() instead of bzero()
      * remove constructor from READ_RECORD() to make it trivial
      * replace some memcpy() with c++ copy assignments
      3d2d060b
    • Alexander Barkov's avatar
    • Monty's avatar
      Fixed bug in redo handling of batch insert in Aria · bb8c82c6
      Monty authored
      The symptom of the bug was that one got the following in
      the aria recovery log:
      "Table 'xxx', id 57, has create_rename_lsn (1,0x12dee) more recent than LOGREC_FILE_ID's LSN (1,0x12dc4), ignoring open request"
      
      After this all future redo entries was marked with
      "For table of short id 57, table skipped, so skipping record"
      
      Analyze:
      When ending batch insert, create_rename_lsn for the table
      is updated to signal that earlier redo entries for the
      table can't be applied. The problem was that future redo
      entries was also ignored as redo code assumed they where
      for the old table.
      
      Fixed by calling translog_dessign_id, which causes
      future redo entries to be seen as belonging to the
      updated table.
      bb8c82c6
    • Monty's avatar
      Fixed compiler warning in connect engine · f2f40a17
      Monty authored
      f2f40a17
    • Marko Mäkelä's avatar
      Datafile::validate_first_page(): Change some ERROR to Note · d3afdb1e
      Marko Mäkelä authored
      On startup, if the InnoDB doublewrite buffer can be used to
      recover a corrupted page, raising an ERROR about a recoverable
      error seems inappropriate. Issue Note instead, and adjust
      tests accordingly.
      
      Also, correctly validate the tablespace ID in the files.
      d3afdb1e