1. 05 Jul, 2023 9 commits
  2. 04 Jul, 2023 10 commits
  3. 03 Jul, 2023 5 commits
  4. 30 Jun, 2023 3 commits
    • Marko Mäkelä's avatar
      MDEV-31559 btr_search_hash_table_validate() does not check if CHECK TABLE is killed · 3d901438
      Marko Mäkelä authored
      btr_search_hash_table_validate(), btr_search_validate(): Add the
      parameter THD for checking if the statement has been killed.
      Any non-QUICK CHECK TABLE will validate the entire adaptive hash index
      for all InnoDB tables, which may be extremely slow when running
      multiple concurrent CHECK TABLE.
      3d901438
    • Marko Mäkelä's avatar
      Merge 10.6 into 10.9 · d04de1aa
      Marko Mäkelä authored
      d04de1aa
    • Oleg Smirnov's avatar
      MDEV-30639 Upgrade to 10.8 and later does not work on Windows · 6d911219
      Oleg Smirnov authored
      During the upgrade procedure on Windows mysqld.exe is started with
      the named pipe connection protocol. mysqladmin.exe then pings the
      server to check if is up and running. Command line looks like:
         mysqladmin.exe --protocol=pipe --socket=mysql_upgrade_service_xxx ping
      But the "socket" parameter resets the "protocol" which was previously
      initialized with the "pipe" value, setting it to "socket".
      As a result, connection cannot be established and the upgrade
      procedure fails.
      "socket" in Windows is used to pass the name of the pipe so resetting
      the protocol is not valid in this case.
      
      This commit fixes resetting of the "protocol" parameter with "socket"
      parameter in the case when protocol has been previously initialized
      to "pipe" value
      6d911219
  5. 29 Jun, 2023 3 commits
    • Alexander Barkov's avatar
      MDEV-31578 DECLARE CURSOR: "Memory not freed: 280 bytes lost" on syntax error · fdab2c4c
      Alexander Barkov authored
      When CURSOR parameters get parsed, their sp_assignment_lex instances
      (one instance per parameter) get collected to List<sp_assignment_lex>.
      
      These instances get linked to sphead only in the end of the list.
      If a syntax error happened in the middle of the parameter list,
      these instances were not deleted, which caused memory leaks.
      
      Fix:
      
      using a Bison %destructor to free rules of the <sp_assignment_lex_list>
      type (on syntax errors).
      
      Afte the fix these sp_assignment_lex instances from CURSOR parameters
      deleted as follows:
      
      - If the CURSOR statement was fully parsed, then these instances
        get properly linked to sp_head structures, so they are deleted
        during ~sp_head (this did not change)
      
      - If the CURSOR statement failed on a syntax error, then by Bison's
        %destructor (this is being added in the current patch).
      fdab2c4c
    • Oleg Smirnov's avatar
      MDEV-30639 Upgrade to 10.8 and later does not work on Windows · 8e2b20bf
      Oleg Smirnov authored
      During the upgrade procedure on Windows mysqld.exe is started with
      the named pipe connection protocol. mysqladmin.exe then pings the
      server to check if is up and running. Command line looks like:
         mysqladmin.exe --protocol=pipe --socket=mysql_upgrade_service_xxx ping
      But the "socket" parameter resets the "protocol" which was previously
      initialized with the "pipe" value, setting it to "socket".
      As a result, connection cannot be established and the upgrade
      procedure fails.
      "socket" in Windows is used to pass the name of the pipe so resetting
      the protocol is not valid in this case.
      
      This commit fixes resetting of the "protocol" parameter with "socket"
      parameter in the case when protocol has been previously initialized
      to "pipe" value
      8e2b20bf
    • Alexander Barkov's avatar
      MDEV-30680 Warning: Memory not freed: 280 on mangled query, LeakSanitizer: detected memory leaks · 0d3720c1
      Alexander Barkov authored
      The parser works as follows:
      
      The rule expr_lex returns a pointer to a newly created sp_expr_lex
      instance which is not linked to any MariaDB structures yet - it is
      pointed only from a Bison stack variable. The sp_expr_lex instance
      gets linked to other structures (such as sp_instr_jump_if_not) later,
      after scanning some following grammar.
      
      Problem before the fix:
      If a parse error happened immediately after expr_lex (before it got linked),
      the created sp_expr_lex value got lost causing a memory leak.
      
      Fix:
      
      - Using Bison's "destructor" directive to free the results of expr_lex
        on parse/oom errors.
      
      - Moving the call for LEX::cleanup_lex_after_parse_error() from
        MYSQL_YYABORT and yyerror inside parse_sql().
        This is needed because Bison calls destructors after yyerror(),
        while it's important to delete the sp_expr_lex instance before
        LEX::cleanup_lex_after_parse_error().
        The latter frees the memory root containing the sp_expr_lex instance.
      
        After this change the code block are executed in the following order:
      
        - yyerror() -- now only raises the error to DA (no cleanup done any more)
        - %destructor { delete $$; } <expr_lex>  -- destructs the sp_expr_lex instance
        - LEX::cleanup_lex_after_parse_error()   -- frees the memory root containing
                                                    the sp_expr_lex instance
      
      - Removing the "delete sublex" related code from restore_lex():
        - restore_lex() is called in most cases on success, when delete is not needed.
        - There is one place when restore_lex() is called on error:
          In sp_create_assignment_instr(). But in this case LEX::sp_lex_in_use
          is true anyway.
          The patch adds a new DBUG_ASSERT(lex->sp_lex_in_use) to guard this.
      0d3720c1
  6. 28 Jun, 2023 6 commits
  7. 27 Jun, 2023 3 commits
  8. 26 Jun, 2023 1 commit