1. 12 Aug, 2021 2 commits
  2. 10 Aug, 2021 1 commit
  3. 05 Aug, 2021 1 commit
  4. 02 Aug, 2021 8 commits
  5. 01 Aug, 2021 1 commit
    • Sergei Golubchik's avatar
      suppress galera error "Failed to report last committed" · ec8882b9
      Sergei Golubchik authored
      according to MDEV-17550 it's informational, not fatal.
      "last committed" is part of the certification index purge process.
      
      depending on what tests and in what order are run it can be triggered
      at unspecified times during the testing. If the test is happen to
      shut down the server at this very time, the log will have:
      
      [Warning] WSREP: Failed to report last committed XXXYYYZZZ, -77 (File descriptor in bad state)
      ec8882b9
  6. 31 Jul, 2021 3 commits
  7. 29 Jul, 2021 4 commits
    • Oleksandr Byelkin's avatar
    • Oleksandr Byelkin's avatar
      Merge branch '10.2' into 10.3 · 83d7e4fa
      Oleksandr Byelkin authored
      83d7e4fa
    • Nikita Malyavin's avatar
      MDEV-20154 Assertion `len <= col->len | ...` failed in row_merge_buf_add · 22709897
      Nikita Malyavin authored
      len was containing garbage, since vctempl->mysql_col_offset was
      containing old value while calling row_mysql_store_col_in_innobase_format
      from innobase_get_computed_value().
      
      It was not updated after the first ALTER TABLE call, because it's INPLACE
      logic considered there's nothing to update, and exited immediately from
      ha_innobase::inplace_alter_table().
      
      However, vcol metadata needs an update, since vcols structure is changed
      in mysql record.
      
      The regression was introduced by 12614af1. There, refcount==1 condition
      was removed, which turned out to be crucial, though racy. The idea was to
      update vc_templ after each (sequencing) ALTER TABLE.
      
      We should do the same another way, and there may be a plenty of solutions,
      but the simplest one is to add a following condition:
        if vcol structure is changed, drop vc_templ; it will be recreated on next
        ha_innobase::open() call.
      
      in prepare_inplace_alter_table. It is safe, since innodb inplace changes
      require at least HA_ALTER_INPLACE_SHARED_LOCK_AFTER_PREPARE, which
      guarantee MDL_EXCLUSIVE on this stage.
      
      alter_templ_needs_rebuild() also has to track the columns not indexed, to
      keep vc_templ correct.
      
      Note that vc_templ is always kept constructed and available after
      ha_innobase::open() call, even on INSERT, though no virtual columns are
      evaluated during that statement
      inside innodb.
      
      In the test case suplied, it will be recreated on the second ALTER TABLE.
      22709897
    • Marko Mäkelä's avatar
      Cleanup: Remove redundant conditions · 0e8981ef
      Marko Mäkelä authored
      ha_innobase::prepare_inplace_alter_table(): Remove always-true conditions.
      Near the start of the function, we would already have returned if
      no ALTER TABLE operation flags were set that would require special
      action from InnoDB.
      
      It turns out that the conditions were redundant already when they were
      introduced in mysql/mysql-server@241387a2b6b61fb8a4f78dc4ad0aaa289400c694
      and in commit 068c6197.
      
      Thanks to Nikita Malyavin for noticing this.
      0e8981ef
  8. 28 Jul, 2021 12 commits
  9. 27 Jul, 2021 8 commits