1. 04 Jul, 2023 11 commits
    • Yuchen Pei's avatar
      MDEV-27095 clean up spd_init_query.h · b4691591
      Yuchen Pei authored
      Removing procedures that were created and dropped during init.
      
      This also fixes a race condition where mtr test with
      plugin-load-add=ha_spider.so causes post test check to fail as it
      expects the procedures to still be there.
      b4691591
    • Yuchen Pei's avatar
      MDEV-27095 installing one spider plugin should not trigger others · 76de38f2
      Yuchen Pei authored
      There are several plugins in ha_spider: spider, spider_alloc_mem,
      spider_wrapper_protocols, spider_rewrite etc.
      
      INSTALL PLUGIN foo SONAME ha_spider causes all the other ones to be
      installed by the init queries where foo is any of the plugins.
      
      This introduces unnecessary complexiy. For example it reads
      mysql.plugins to find all other plugins, causing the hack of moving
      spider plugin init to a separate thread.
      
      To install all spider related plugins, install soname ha_spider should
      be used instead.
      
      This also fixes spurious rows in mysql.plugin when installing say only
      the spider plugin with `plugin-load-add=SPIDER=ha_spider.so`:
      
      select * from mysql.plugin;
      name	dl
      spider_alloc_mem	ha_spider.so # should not be here
      spider_wrapper_protocols	ha_spider.so # should not be here
      
      Adapted from part of the reverted commit
      c160a115.
      76de38f2
    • Yuchen Pei's avatar
      MDEV-31400 Simple plugin dependency resolution · b3139c72
      Yuchen Pei authored
      We introduce simple plugin dependency. A plugin init function may
      return HA_ERR_RETRY_INIT. If this happens during server startup when
      the server is trying to initialise all plugins, the failed plugins
      will be retried, until no more plugins succeed in initialisation or
      want to be retried.
      
      This will fix spider init bugs which is caused in part by its
      dependency on Aria for initialisation.
      
      The reason we need a new return code, instead of treating every
      failure as a request for retry, is that it may be impossible to clean
      up after a failed plugin initialisation. Take InnoDB for example, it
      has a global variable `buf_page_cleaner_is_active`, which may not
      satisfy an assertion during a second initialisation try, probably
      because InnoDB does not expect the initialisation to be called
      twice.
      b3139c72
    • Yuchen Pei's avatar
      MDEV-31421 Fix spider test cleanup · 7245f2c0
      Yuchen Pei authored
      This fixes mdev_26541.test, and the new clean_up_spider.inc will be
      useful for other tests where part of deinit_spider does not apply,
      e.g. those testing spider initialisation only.
      7245f2c0
    • Yuchen Pei's avatar
    • Yuchen Pei's avatar
      Adding .ccls-cache/ to .gitignore · 8cebd285
      Yuchen Pei authored
      generated by the language server ccls
      8cebd285
    • Yuchen Pei's avatar
      MDEV-30542 Fixing spider/bugfix.self_reference_multi · 2d4274ae
      Yuchen Pei authored
      The server needs to have a unique name
      2d4274ae
    • Yuchen Pei's avatar
      MDEV-31101 Spider: temporarily disable mdev_29904.test · 1b89f69f
      Yuchen Pei authored
      Will re-enable once MDEV-31101 is no longer blocked by MDEV-22979,
      as the patch for the latter might fix the former.
      1b89f69f
    • Yuchen Pei's avatar
      MDEV-29447 MDEV-26285 MDEV-31338 Refactor spider_db_mbase_util::open_item_func · 3a1d6d4b
      Yuchen Pei authored
      spider_db_mbase_util::open_item_func() is a monster function.
      It is difficult to maintain while it is expected that we need to
      modify it when a new SQL function or a new func_type is added.
      
      We split the function into two distinct functions: one handles the
      case of str != NULL and the other handles the case of str == NULL.
      
      This refactoring was done in a conservative way because we do not
      have comprehensive tests on the function.
      
      It also fixes MDEV-29447 and MDEV-31338 where field items that are
      arguments of a func item may be used before created / initialised.
      
      Note this commit is adapted from a patch by Nayuta for MDEV-26285.
      3a1d6d4b
    • Yuchen Pei's avatar
      MDEV-30435 MDEV-30981 Fix ubsan errors w.r.t. memcpy in spd_trx.cc · 308c62f8
      Yuchen Pei authored
      Extract the indexed string memcopy pattern in spd_trx.cc to a static
      inline function.
      
      Also updated the ubsan check in mdev_26541.test (h/t roel).
      308c62f8
    • Yuchen Pei's avatar
      MDEV-31463 [fixup] Spider: error code in mdev_31463.test · a9e13866
      Yuchen Pei authored
      The error code is non-deterministic, presumably due to some race
      condition from the SLEEP statement above. The correct error should be
      12701 ER_SPIDER_REMOTE_SERVER_GONE_AWAY_NUM as it is the last failure.
      Nevertheless, this contrived test is needed to cover the error
      reporting when setting lock wait timeout, until we find a better test
      case and/or fixing the non-deterministic error reporting (MDEV-31586)
      a9e13866
  2. 02 Jul, 2023 2 commits
  3. 28 Jun, 2023 2 commits
    • Marko Mäkelä's avatar
      Merge 10.11 into 11.0 · 1fe4bcbe
      Marko Mäkelä authored
      1fe4bcbe
    • Yuchen Pei's avatar
      MDEV-31463 Spider should check connection before setting lock wait timeout · 5ef27d27
      Yuchen Pei authored
      When setting the server lockwait timeout, spider should do some basic
      checks first, like whether the remote server is still reachable. So
      instead of directly calling spider_db_mbase::exec_query(), it should
      call spider_db_query().
      
      The reset of the lock wait timeout does not need to do such checks,
      because they happen after the successfully setting the lock wait
      timeout, implying the checks have been passed already.
      5ef27d27
  4. 27 Jun, 2023 5 commits
  5. 26 Jun, 2023 3 commits
  6. 25 Jun, 2023 9 commits
  7. 21 Jun, 2023 3 commits
    • Brandon Nesterenko's avatar
      MDEV-29894: Calling a function from a different database in a slave side trigger crashes · c2d44ecb
      Brandon Nesterenko authored
      When opening and locking tables, if triggers will be invoked in a
      separate database, thd->set_db() is invoked, thus freeeing the memory
      and headers which thd->db had previously pointed to. In row based
      replication, the event execution logic initializes thd->db to point
      to the database which the event targets, which is owned by the
      corresponding table share (introduced in d9898c9a for MDEV-7409).
      The problem then, is that during the table opening and locking
      process for a row event, memory which belongs to the table share
      would be freed, which is not valid.
      
      This patch replaces the thd->reset_db() calls to thd->set_db(),
      which copies-by-value, rather than by reference. Then when the
      memory is freed, our copy of memory is freed, rather than memory
      which belongs to a table share.
      
      Notes:
        1. The call to change thd->db now happens on a higher-level, in
      Rows_log_event::do_apply_event() rather than ::do_exec_row(), in the
      call stack. This is because do_exec_row() is called within a loop,
      and each invocation would redundantly set and unset the db to the
      same value.
        2. thd->set_db() is only used if triggers are to be invoked, as
      there is no vulnerability in the non-trigger case, and copying
      memory would be an unnecessary inefficiency.
      
      Reviewed By:
      ============
      Andrei Elkin <andrei.elkin@mariadb.com>
      c2d44ecb
    • Monty's avatar
      MDEV-31375 Assertion `dbl_records <= s->records' failed with optimizer_use_condition_selectivity=1 · 3d617fdc
      Monty authored
      The reason for the crash wad that 'best splitting' optimization
      predicted less rows to be found than what opt_range did.
      This code in apply_selectivity_for_table(), when using use_cond_selectivity=1,
      was not prepared for this case which caused an assert in debug builds.
      Production builds is not affected.
      
      The fix is to choose the smaller of the two row counts. It will have a
      minimum on costs when using use_cond_selectivity=1 and should not cause
      any problems in production.
      3d617fdc
    • Monty's avatar
      MDEV-31494 Server crashes in ha_partition::index_blocks / get_key_scans_params · d3c81804
      Monty authored
      MDEV-31445 Server crashes in ha_partition::index_blocks / cost_for_index_read
      
      The crash happened in the case where partition pruning finds 0
      partitions.
      d3c81804
  8. 20 Jun, 2023 1 commit
  9. 19 Jun, 2023 1 commit
  10. 18 Jun, 2023 1 commit
  11. 16 Jun, 2023 1 commit
  12. 15 Jun, 2023 1 commit