1. 25 Jan, 2021 2 commits
  2. 22 Jan, 2021 2 commits
  3. 21 Jan, 2021 3 commits
    • Sergei Golubchik's avatar
      MDEV-24593 Signal 11 when group by primary key of table joined to information_schema.columns · 4e503aec
      Sergei Golubchik authored
      I_S tables were materialized too late, an attempt to use table
      statistics before the table was created caused a crash.
      
      Let's move table creation up. it only needs read_set to
      be calculated properly, this happens in JOIN::optimize_inner(),
      after semijoin transformation.
      
      Note that tables are not populated at that point, so most of the
      statistics would make no sense anyway. But at least field sizes
      will be correct. And it won't crash.
      4e503aec
    • Sergei Golubchik's avatar
      remove now-unused rdiff file · 61feb568
      Sergei Golubchik authored
      61feb568
    • Jan Lindström's avatar
      MDEV-24596 : Assertion `state_ == s_exec || state_ == s_quitting' failed in... · be5fce16
      Jan Lindström authored
      MDEV-24596 : Assertion `state_ == s_exec || state_ == s_quitting' failed in wsrep::client_state::disable_streaming
      
      There were multiple problems here
      * wsrep_trx_fragment_size should not be set when wsrep is disabled or provider is not loaded
      * wsrep_trx_fragment_unit should not be set when wsrep is disabled or provider is not loaded
      * wsrep_debug has no effect if wsrep is disabled or provider is not loaded
      * wsrep_start_position should not be set when wsrep is disabled or provider is not loaded any other value than default
      * wsrep_start_position should be changed only when we are joiner or initialized
      * wsrep_start_position should be allowed to set only a value that exits, thus
      we need to add error handling to wsrep_sst_complete
      be5fce16
  4. 20 Jan, 2021 1 commit
    • sjaakola's avatar
      MDEV-21153 Replica nodes crash due to indexed virtual columns and FK cascading delete · 9377e9ba
      sjaakola authored
      Fix for MDEV-23033 fixes a problem in replication applying of transactions, which contain cascading foreign key delete for a table, which has indexed virtual column.
      This fix adds slave_fk_event_map flag for table, to mark when the prelocking is needed for applying of a transaction.
      See commit 608b0ee5 for more details.
      However, this fix is targeted for async replication only, Rows_log_event::do_apply_event() has condition to rule out galera replication from the fix domain, and use cases suffering from MDEV-23033 and related MDEV-21153 will fail in galera cluster.
      
      The fix in this commit removes the condition to rule out the setting of slave_fk_event_map flag from galera replication, and makes the fix in MDEV-23033 effective for galera replication as well.
      
      However, the above fix has caused regressions for some galera_sr suite tests, which run tests for streaming replication.
      This regression can be observed e.g. by: /mtr galera_sr.galera_sr_multirow_rollback  --mysqld=--slave_run_triggers_for_rbr=yes
      These galera_sr suite tests were failing in last phase of replication applying, where actual transaction is already applied, and streaming replication related meta data needs to be updated in wsrep system tables.
      Opening the wsrep system tables failed for corrupt data in THD::lex:query_tables_list. The fix in this commit uses back query table list for the duration of fragment update operation.
      
      Finally, a mtr test for virtual column support has been added. galera.galera_virtual_column.test has as first test a scenario from MDEV-21153
      
      new fix
      Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
      9377e9ba
  5. 19 Jan, 2021 3 commits
    • sjaakola's avatar
      MDEV-21153 Replica nodes crash due to indexed virtual columns and FK cascading delete · 7d04ce6a
      sjaakola authored
      Fix for MDEV-23033 fixes a problem in replication applying of transactions, which contain cascading foreign key delete for a table, which has indexed virtual column.
      This fix adds slave_fk_event_map flag for table, to mark when the prelocking is needed for applying of a transaction.
      See commit 608b0ee5 for more details.
      However, this fix is targeted for async replication only, Rows_log_event::do_apply_event() has condition to rule out galera replication from the fix domain, and use cases suffering from MDEV-23033 and related MDEV-21153 will fail in galera cluster.
      
      The fix in this commit removes the condition to rule out the setting of slave_fk_event_map flag from galera replication, and makes the fix in MDEV-23033 effective for galera replication as well.
      
      Finally, a mtr test for virtual column support has been added. galera.galera_virtual_column.test has as first test a scenario from MDEV-21153
      Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
      7d04ce6a
    • Dmitry Shulga's avatar
      MDEV-24577: Fix warnings generated during compilation of... · 8bcddb02
      Dmitry Shulga authored
      MDEV-24577: Fix warnings generated during compilation of plugin/auth_pam/testing/pam_mariadb_mtr.c on FreeBSD
      
      Compiler warnings generated on building MariaDB server for BSD has the same
      reason as in case building is performed on MacOS. Both platforms do use
      clang as a C/C++ compiler. So, fix the compiler warnings in case the compiler
      is clang doesn't matter what kind of building platform do we use for building.
      
      This is a follow-up patch for the following bug reports:
        MDEV-23564: CMAKE failing due to deprecated Apple GSS method
        MDEV-23935: Fix warnings generated during compilation of
                    plugin/auth_pam/testing/pam_mariadb_mtr.c on MacOS
      8bcddb02
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 049811ec
      Marko Mäkelä authored
      049811ec
  6. 14 Jan, 2021 2 commits
    • Jan Lindström's avatar
      MDEV-22285 : Assertion `xid_seqno > wsrep_seqno' failed in... · b87828b6
      Jan Lindström authored
      MDEV-22285 : Assertion `xid_seqno > wsrep_seqno' failed in trx_rseg_update_wsrep_checkpoint on SET @@global.wsrep_start_position
      
      Actual assertion mentioned on MDEV seems to be already fixed but
      setting seqno to -2 will trigger a different assertion
      
      mysqld: /home/jan/mysql/10.4-bugs/wsrep-lib/src/server_state.cpp:702: void wsrep::server_state::sst_received(wsrep::client_service&, int): Assertion `state_ == s_joiner || state_ == s_initialized' failed.
      
      Fixed this by not allowing user to set seqno < -1 (-1 is special
      seqno meaning undefined and seqno is initialized to it). MariaDB
      releases 10.2 and 10.3 already do not allow to set seqno < -1.
      b87828b6
    • Dmitry Shulga's avatar
      MDEV-23666: Assertion `m_cpp_buf <= ptr && ptr <= m_cpp_buf + m_buf_length'... · f130adbf
      Dmitry Shulga authored
      MDEV-23666: Assertion `m_cpp_buf <= ptr && ptr <= m_cpp_buf + m_buf_length' failed in Lex_input_stream::body_utf8_append
      
      On parsing statements for which a starting backtick (`) delimiter doesn't have
      a corresponding ending backtick, a current pointer to a position inside a
      pre-processed buffer could go beyond the end of the buffer.
      
      This bug report caused by the commit d4967659
        "MDEV-22022 Various mangled SQL statements will crash 10.3 to 10.5 debug builds".
      
      In order to fix the issue both pointers m_ptr and m_cpp_ptr must be
      rolled back to previous position in raw input and pre-processed input streams
      correspondingly in case end of query reached during parsing.
      f130adbf
  7. 13 Jan, 2021 3 commits
  8. 12 Jan, 2021 12 commits
  9. 11 Jan, 2021 3 commits
  10. 09 Jan, 2021 2 commits
  11. 08 Jan, 2021 6 commits
    • Jan Lindström's avatar
      MDEV-23536 : Race condition between KILL and transaction commit · 775fccea
      Jan Lindström authored
      A race condition may occur between the execution of transaction commit,
      and an execution of a KILL statement that would attempt to abort that
      transaction.
      
      MDEV-17092 worked around this race condition by modifying InnoDB code.
      After that issue was closed, Sergey Vojtovich pointed out that this
      race condition would better be fixed above the storage engine layer:
      
      If you look carefully into the above, you can conclude that
      thd->free_connection() can be called concurrently with
      KILL/thd->awake(). Which is the bug. And it is partially fixed in
      THD::~THD(), that is destructor waits for KILL completion:
      
      Fix: Add necessary mutex operations to THD::free_connection()
      and move WSREP specific code also there. This ensures that no
      one is using THD while we do free_connection(). These mutexes
      will also ensures that there can't be concurrent KILL/THD::awake().
      
      innobase_kill_query
        We can now remove usage of trx_sys_mutex introduced on MDEV-17092.
      
      trx_t::free()
        Poison trx->state and trx->mysql_thd
      
      This patch is validated with an RQG run similar to the one that
      reproduced MDEV-17092.
      775fccea
    • Marko Mäkelä's avatar
      18254c18
    • Nikita Malyavin's avatar
      fixup MDEV-17556: fix mroonga · 61a362c9
      Nikita Malyavin authored
      61a362c9
    • Jan Lindström's avatar
      Update wsrep-lib · 26d913a7
      Jan Lindström authored
      26d913a7
    • Marko Mäkelä's avatar
      cd1e5d65
    • Nikita Malyavin's avatar
      MDEV-17556 Assertion `bitmap_is_set_all(&table->s->all_set)' failed · e25623e7
      Nikita Malyavin authored
      The assertion failed in handler::ha_reset upon SELECT under
      READ UNCOMMITTED from table with index on virtual column.
      
      This was the debug-only failure, though the problem is mush wider:
      * MY_BITMAP is a structure containing my_bitmap_map, the latter is a raw
       bitmap.
      * read_set, write_set and vcol_set of TABLE are the pointers to MY_BITMAP
      * The rest of MY_BITMAPs are stored in TABLE and TABLE_SHARE
      * The pointers to the stored MY_BITMAPs, like orig_read_set etc, and
       sometimes all_set and tmp_set, are assigned to the pointers.
      * Sometimes tmp_use_all_columns is used to substitute the raw bitmap
       directly with all_set.bitmap
      * Sometimes even bitmaps are directly modified, like in
      TABLE::update_virtual_field(): bitmap_clear_all(&tmp_set) is called.
      
      The last three bullets in the list, when used together (which is mostly
      always) make the program flow cumbersome and impossible to follow,
      notwithstanding the errors they cause, like this MDEV-17556, where tmp_set
      pointer was assigned to read_set, write_set and vcol_set, then its bitmap
      was substituted with all_set.bitmap by dbug_tmp_use_all_columns() call,
      and then bitmap_clear_all(&tmp_set) was applied to all this.
      
      To untangle this knot, the rule should be applied:
      * Never substitute bitmaps! This patch is about this.
       orig_*, all_set bitmaps are never substituted already.
      
      This patch changes the following function prototypes:
      * tmp_use_all_columns, dbug_tmp_use_all_columns
       to accept MY_BITMAP** and to return MY_BITMAP * instead of my_bitmap_map*
      * tmp_restore_column_map, dbug_tmp_restore_column_maps to accept
       MY_BITMAP* instead of my_bitmap_map*
      
      These functions now will substitute read_set/write_set/vcol_set directly,
      and won't touch underlying bitmaps.
      e25623e7
  12. 07 Jan, 2021 1 commit