1. 11 Sep, 2024 4 commits
    • Monty's avatar
      MDEV-34867 engine S3 cause 500 error for huawei buckets · 3ae4ecbf
      Monty authored
      Add support for removing the Content-Type header to the S3 engine. This
      is required for compatibility with some S3 providers.
      
      This also adds a provider option to the S3 engine which will turn on
      relevant compatibility options for specific providers.
      
      This was required for getting MariaDB S3 engine to work with "Huawei
      Cloud S3".
      To get Huawei S3 storage to work on has set one of the following
      S3 options:
      s3_provider=Huawei
      s3_ssl_no_verify=1
      
      Author: Andrew Hutchings <andrew@mariadb.org>
      3ae4ecbf
    • Sergei Petrunia's avatar
    • Yuchen Pei's avatar
      Merge branch '10.5' into 10.6 · 4a09e743
      Yuchen Pei authored
      4a09e743
    • Daniel Black's avatar
      MDEV-34650 main.having_cond_pushdown test failure - crash server (s390x) · 02b30044
      Daniel Black authored
      The 10.5->10.6 merge commit 3bc98a4e casts the arg to an int16
      pointer in set_extraction_flag_processor(). This matched the previous
      commit c76eabfb where set_extraction_flag was changed to have int16 arg
      instead of int.
      
      The commit a5e4c349 for MDEV-29363 added a call to
      set_extraction_flag_processor on IMMUTABLE_FL (MARKER_IMMUTABLE in 10.6).
      The subsequent 10.5->10.6 merge f071b762 did not cast the flag
      to int16 when merging this change.
      
      The result is big-endian processors cleared the immutable
      flag rather than set the flag, resulting in MDEV-29363
      being unfixed on big-endian processors.
      02b30044
  2. 10 Sep, 2024 22 commits
  3. 09 Sep, 2024 1 commit
  4. 08 Sep, 2024 1 commit
    • Sergei Petrunia's avatar
      MDEV-34894: Poor query plan, because range estimates are not reused for ref(const) · c630e23a
      Sergei Petrunia authored
      (Variant 4, with @@optimizer_adjust_secondary_key_costs, reuse in two
      places, and conditions are replaced with equivalent simpler forms in two more)
      
      In best_access_path(), ReuseRangeEstimateForRef-3,  the check
      for whether
       "all used key_part_i used key_part_i=const"
      was incorrect: it may produced a "NO" answer for cases when we
      had:
       key_part1= const // some key parts are usable
       key_part2= value_not_in_join_prefix  //present but unusable
       key_part3= non_const_value // unusable due to gap in key parts.
      
      This caused the optimizer to fail to apply ReuseRangeEstimateForRef
      heuristics. The consequence is poor query plan choice when the index
      in question has very skewed data distribution.
      
      The fix is enabled if its @@optimizer_adjust_secondary_key_costs flag
      is set.
      c630e23a
  5. 07 Sep, 2024 2 commits
  6. 06 Sep, 2024 7 commits
    • Monty's avatar
      Removed ctrl-l from the source · f0b2e765
      Monty authored
      f0b2e765
    • Marko Mäkelä's avatar
      f06060f5
    • Marko Mäkelä's avatar
      MDEV-34823 Invalid arguments in ib_push_warning() · 024a18db
      Marko Mäkelä authored
      In the bug report MDEV-32817 it occurred that the function
      row_mysql_get_table_status() is outputting a fil_space_t*
      as if it were a numeric tablespace identifier.
      
      ib_push_warning(): Remove. Let us invoke push_warning_printf() directly.
      
      innodb_decryption_failed(): Report a decryption failure and set the
      dict_table_t::file_unreadable flag. This code was being duplicated in
      very many places. We return the constant value DB_DECRYPTION_FAILED
      in order to avoid code duplication in the callers and to allow tail calls.
      
      innodb_fk_error(): Report a FOREIGN KEY error.
      
      dict_foreign_def_get(), dict_foreign_def_get_fields(): Remove.
      This code was being used in dict_create_add_foreign_to_dictionary()
      in an apparently uncovered code path. That ib_push_warning() call
      would pass the integer i+1 instead of a pointer to NUL terminated
      string ("%s"), and therefore the call should have resulted in a crash.
      
      dict_print_info_on_foreign_key_in_create_format(),
      innobase_quote_identifier(): Add const qualifiers.
      
      row_mysql_get_table_error(): Replaces row_mysql_get_table_status().
      Display no message on DB_CORRUPTION; it should be properly reported at
      the SQL layer anyway.
      024a18db
    • Yuchen Pei's avatar
      Merge branch '10.5' into 10.6 · 60b93cdd
      Yuchen Pei authored
      60b93cdd
    • Yuchen Pei's avatar
    • Yuchen Pei's avatar
      MDEV-33858 Assertion `(mem_root->flags & 4) == 0' fails on 2nd execution of PS... · 00cb3440
      Yuchen Pei authored
      MDEV-33858 Assertion `(mem_root->flags & 4) == 0' fails on 2nd execution of PS with -DWITH_PROTECT_STATEMENT_MEMROOT=ON
      
      Simply adding tests as the bug is fixed with a backport of MDEV-34447
      00cb3440
    • Yuchen Pei's avatar
      MDEV-34447: Memory leakage is detected on running the test main.ps against the server 11.1 · 2c3e07df
      Yuchen Pei authored
      The memory leak happened on second execution of a prepared statement
      that runs UPDATE statement with correlated subquery in right hand side of
      the SET clause. In this case, invocation of the method
        table->stat_records()
      could return the zero value that results in going into the 'if' branch
      that handles impossible where condition. The issue is that this condition
      branch missed saving of leaf tables that has to be performed as first
      condition optimization activity. Later the PS statement memory root
      is marked as read only on finishing first time execution of the prepared
      statement. Next time the same statement is executed it hits the assertion
      on attempt to allocate a memory on the PS memory root marked as read only.
      This memory allocation takes place by the sequence of the following
      invocations:
       Prepared_statement::execute
        mysql_execute_command
         Sql_cmd_dml::execute
          Sql_cmd_update::execute_inner
           Sql_cmd_update::update_single_table
            st_select_lex::save_leaf_tables
             List<TABLE_LIST>::push_back
      
      To fix the issue, add the flag SELECT_LEX::leaf_tables_saved to control
      whether the method SELECT_LEX::save_leaf_tables() has to be called or
      it has been already invoked and no more invocation required.
      
      Similar issue could take place on running the DELETE statement with
      the LIMIT clause in PS/SP mode. The reason of memory leak is the same as for
      UPDATE case and be fixed in the same way.
      2c3e07df
  7. 05 Sep, 2024 3 commits