1. 11 Oct, 2023 2 commits
    • Yuchen Pei's avatar
      MDEV-31996 Create connection on demand in spider_db_delete_all_rows · 2556fe1a
      Yuchen Pei authored
      When spider_db_delete_all_rows() is called, the supplied spider->conns
      may have already been freed. The existing mechanism has spider_trx own
      the connections in trx_conn_hash and it may free a conn during the
      cleanup after a query. When running a delete query and if the table is
      in the table cache, ha_spider::open() would not be called which would
      recreate the conn. So we recreate the conn when necessary during
      delete by calling spider_check_trx_and_get_conn().
      
      We also reduce code duplication as delete_all_rows() and truncate()
      has almost identical code, and there's no need to assign
      wide_handler->sql_command in these functions because it has already
      been correctly assigned.
      2556fe1a
    • Vladislav Vaintroub's avatar
  2. 10 Oct, 2023 3 commits
    • Vladislav Vaintroub's avatar
      MDEV-32387 Windows - mtr output on is messed up with large MTR_PARALLEL. · f197f9a5
      Vladislav Vaintroub authored
      Windows C runtime does not implement line buffering mode for stdio.
      
      This sometimes makes output from different tests interleaved in MTR
      MTR relies on this buffering (lines won't  output until "\n") to correctly
      work in parallel scenarios.
      
      Implement do-it-yourself line buffering on Windows, to workaround.
      f197f9a5
    • Vladislav Vaintroub's avatar
      MDEV-32387 Windows - mtr output on is messed up with large MTR_PARALLEL. · 19423636
      Vladislav Vaintroub authored
      Windows C runtime does not implement line buffering mode for stdio.
      
      This sometimes makes output from different tests interleaved in MTR
      MTR relies on this buffering (lines won't  output until "\n") to correctly
      workin parallel scenarios.
      
      Implement do-it-yourself line buffering on Windows, to workaround.
      19423636
    • Oleg Smirnov's avatar
      MDEV-30664 mysqldump output is truncated on Windows · cbe61bf8
      Oleg Smirnov authored
      Flush stdout on finalizing of mysqldump/mysqlbinlog output
      to avoid truncation.
      
      The same patch has been applied to the mysqltest.cc code with
        commit 34ff714b
        Author: Magnus Svensson <msvensson@mysql.com>
        Date:   Fri Nov 14 11:06:56 2008 +0100
          WL#4189 Make mysqltest flush log file at close if logfile is stdout
      
      but not to mysqldump.c/mysqlbinlog.cc
      cbe61bf8
  3. 09 Oct, 2023 1 commit
  4. 06 Oct, 2023 2 commits
  5. 05 Oct, 2023 3 commits
  6. 04 Oct, 2023 2 commits
    • Alexander Barkov's avatar
      MDEV-32275 getting error 'Illegal parameter data types row and bigint for... · 534a2bf1
      Alexander Barkov authored
      MDEV-32275 getting error 'Illegal parameter data types row and bigint for operation '+' ' when using ITERATE in a FOR..DO
      
      An "ITERATE innerLoop" did not work properly inside
      a WHILE loop, which itself is inside an outer FOR loop:
      
      outerLoop:
        FOR
         ...
         innerLoop:
          WHILE
            ...
            ITERATE innerLoop;
            ...
          END WHILE;
          ...
        END FOR;
      
      It erroneously generated an integer increment code for the outer FOR loop.
      There were two problems:
      1. "ITERATE innerLoop" worked like "ITERATE outerLoop"
      2. It was always integer increment, even in case of FOR cursor loops.
      
      Background:
      - A FOR loop automatically creates a dedicated sp_pcontext stack entry,
        to put the iteration and bound variables on it.
      
      - Other loop types (LOOP, WHILE, REPEAT), do not generate a dedicated
        slack entry.
      
        The old code erroneously assumed that sp_pcontext::m_for_loop
        either describes the most inner loop (in case the inner loop is FOR),
        or is empty (in case the inner loop is not FOR).
      
        But in fact, sp_pcontext::m_for_loop is never empty inside a FOR loop:
        it describes the closest FOR loop, even if this FOR loop has nested
        non-FOR loops inside.
      
        So when we're near the ITERATE statement in the above script,
        sp_pcontext::m_for_loop is not empty - it stores information about
        the FOR loop labeled as "outrLoop:".
      
      Fix:
      - Adding a new member sp_pcontext::Lex_for_loop::m_start_label,
        to remember the explicit or the auto-generated label correspoding
        to the start of the FOR body. It's used during generation
        of "ITERATE loop_label" code to check if "loop_label" belongs
        to the current FOR loop pointed by sp_pcontext::m_for_loop,
        or belongs to a non-FOR nested loop.
      
      - Adding LEX methods sp_for_loop_intrange_iterate() and
        sp_for_loop_cursor_iterate() to reuse the code between
        methods handling:
        * ITERATE
        * END FOR
      
      - Adding a test for Lex_for_loop::is_for_loop_cursor()
        and generate a code either a cursor fetch, or for an integer increment.
        Before this change, it always erroneously generated an integer increment
        version.
      
      - Cleanup: Initialize Lex_for_loop_st::m_cursor_offset inside
        Lex_for_loop_st::init(), to avoid not initialized members.
      
      - Cleanup: Removing a redundant method:
          Lex_for_loop_st::init(const Lex_for_loop_st &other)
        Using Lex_for_loop_st::operator(const Lex_for_loop_st &other) instead.
      534a2bf1
    • Alexander Barkov's avatar
      MDEV-28835 Assertion `(length % 4) == 0' failed in my_lengthsp_utf32 on INSERT · e2da748c
      Alexander Barkov authored
      Problem:
      
      Item_func_date_format::val_str() and make_date_time() did not take into
      account that the format string and the result string
      (separately or at the same time) can be of a tricky character set
      like UCS2, UTF16, UTF32. As a result, DATE_FORMAT() could generate
      an ill-formed result which crashed on DBUG_ASSERTs testing well-formedness
      in other parts of the code.
      
      Fix:
      
      1. class String changes
         Removing String::append_with_prefill(). It was not compatible with
         tricky character sets. Also it was inconvenient to use and required
         too much duplicate code on the caller side.
         Adding String::append_zerofill() instead. It's compatible with tricky
         character sets and is easier to use.
         Adding helper methods Static_binary_string::q_append_wc() and
         String::append_wc(), to append a single wide character
         (a Unicode code point in my_wc_t).
      
      2. storage/spider changes
         Removing spider_string::append_with_prefill().
         It used String::append_with_prefix() inside, but it was unused itself.
      
      3. Changing tricky charset incompatible code pieces in make_date_time()
         to compatible replacements:
      
         - Fixing the loop scanning the format string to iterate in terms
           of Unicode code points (using mb_wc()) rather than in terms
           of "char" items.
         - Using append_wc(my_wc_t) instead of append(char) to append
           a single character to the result string.
         - Using append_zerofill() instead of append_with_prefill() to
           append date/time numeric components to the result string.
      e2da748c
  7. 03 Oct, 2023 1 commit
  8. 29 Sep, 2023 3 commits
  9. 28 Sep, 2023 3 commits
  10. 27 Sep, 2023 5 commits
  11. 26 Sep, 2023 6 commits
  12. 25 Sep, 2023 3 commits
    • Daniel Black's avatar
      MDEV-18200 MariaBackup full backup failed with InnoDB: Failing assertion: success · ca66a2cb
      Daniel Black authored
      There are many filesystem related errors that can occur with
      MariaBackup. These already outputed to stderr with a good description of
      the error. Many of these are permission or resource (file descriptor)
      limits where the assertion and resulting core crash doesn't offer
      developers anything more than the log message. To the user, assertions
      and core crashes come across as poor error handling.
      
      As such we return an error and handle this all the way up the stack.
      ca66a2cb
    • Vlad Lesin's avatar
      MDEV-25163 Rowid filter does not process storage engine error correctly. · 275f4343
      Vlad Lesin authored
      The fix is to return 3-state value from Range_rowid_filter::build()
      call:
      1. The filter was built successfully;
      2. The filter was not built, but the error was not fatal, i.e. there is
      no need to rollback transaction. For example, if the size of container to
      storevrow ids is not enough;
      3. The filter was not built because of fatal error, for example,
      deadlock or lock wait timeout from storage engine. In this case we
      should stop query plan execution and roll back transaction.
      
      Reviewed by: Sergey Petrunya
      275f4343
    • Yuchen Pei's avatar
      MDEV-31936 Simplify deinit_spider.inc · b6773f58
      Yuchen Pei authored
      Spider is part of the server, and there's no need to check the
      version.
      
      All spider plugins are uninstalled in clean_up_spider.inc
      
      DROP SERVER IF EXISTS makes things easier
      b6773f58
  13. 24 Sep, 2023 1 commit
  14. 22 Sep, 2023 3 commits
  15. 20 Sep, 2023 2 commits
    • Oleksandr Byelkin's avatar
      Make WITH_WSREP=NO built with clang · 5a7bcf16
      Oleksandr Byelkin authored
      5a7bcf16
    • Oleg Smirnov's avatar
      MDEV-29731 Assertion failure when HAVING in a correlated subquery references... · 73ef86d4
      Oleg Smirnov authored
      MDEV-29731 Assertion failure when HAVING in a correlated subquery references columns in the outer query
      
      When resolving a column from the HAVING clause, a new Item_field
      object may be created inside Item_ref::fix_fields().
      But the object is created with an empty name resolution context,
      which then leads to debug assertion failure during
      Item_field::fix_fields().
      
      The solution is to pass the correct name resolution context
      when creating the Item_field object.
      
      Reviewer: Oleksandr Byelkin (sanja@mariadb.com)
      73ef86d4