1. 08 Jan, 2024 3 commits
  2. 04 Jan, 2024 1 commit
  3. 03 Jan, 2024 3 commits
    • Igor Babaev's avatar
      MDEV-31657 Crash on query using CTE with the same name as a base table · 54ed3939
      Igor Babaev authored
      If a query contained a CTE whose name coincided with the name of one of
      the base tables used in the specification of the CTE and the query had at
      least two references to this CTE in the specifications of other CTEs then
      processing of the query led to unlimited recursion that ultimately caused
      a crash of the server.
      
      Any secondary non-recursive reference to a CTE requires creation of a copy
      of the CTE specification. All the references to CTEs in this copy must be
      resolved. If the specification contains a reference to a base table whose
      name coincides with the name of then CTE then it should be ensured that
      this reference in no way can be resolved against the name of the CTE.
      54ed3939
    • Marko Mäkelä's avatar
      MDEV-33157 WSREP: Fix function pointer mismatch · 96130b18
      Marko Mäkelä authored
      wsrep_plugin_init(), wsrep_plugin_deinit(): Remove these dummy functions
      in order to fix an error that would be flagged by cmake -DWITH_UBSAN=ON
      when using clang.
      
      wsrep_show_ready(), wsrep_show_bf_aborts(): Correct the signature.
      96130b18
    • Igor Babaev's avatar
      MDEV-29362 Crash with query using constant subquery as left part of IN subquery · 832e96de
      Igor Babaev authored
      If a query has a HAVING clause that contains a predicate with a constant
      IN subquery whose lef part in its turn is a subquery and the predicate is
      subject to pushdown from HAVING to WHERE then execution of the query could
      cause a crash of the server.
      
      The cause of the problem was the missing implementation of the walk()
      method for the class Item_in_optimizer. As a result in some cases the left
      operand of the Item_in_optimizer condition could be traversed twice by
      the walk procedure. For many call-back functions used as an argument of
      this procedure it does not matter. Yet it matters for the call-back
      function cleanup_excluding_immutables_processor() used in pushdown of
      predicates from HAVING to WHERE. If the processed item is marked with
      the IMMUTABLE_FL flag then the processor just removes this flag, otherwise
      it performs cleanup of the item making it unfixed. If an item is marked
      with an the IMMUTABLE_FL and it traversed with this processor twice then
      it becomes unfixed after the second traversal though the flag indicates
      that the item should not be cleaned up.
      
      Approved by Oleksandr Byelkin <sanja@mariadb.com>
      832e96de
  4. 27 Dec, 2023 3 commits
    • Alexander Barkov's avatar
      MDEV-33019 The database part is not case sensitive in SP names · 9695974e
      Alexander Barkov authored
      Problem:
      
      sp_cache erroneously looked up fully qualified SP names (e.g. `DB`.`SP`),
      in case insensitive style. It was wrong, because only the "name"
      part is always case insensitive, while the "db" part should be compared
      according to lower_case_table_names (case sensitively for 0,
      case insensitively for 1 and 2).
      
      Fix:
      
      Adding a "casedn_name" parameter make_qname() to tell
      if the name part should be lower cased:
        `DB1`.`SP` -> "DB1.SP"  (when casedn_name=false)
        `DB1`.`SP` -> "DB1.sp"  (when casedn_name=true)
      and using make_qname() with casedn_name=true when creating
      sp_cache hash lookup keys.
      
      Details:
      
      As a result, it now works as follows:
      - sp_head::m_db is converted to lower case if lower_case_table_names>0
        during the sp_name initialization phase. So when make_qname() is called,
        sp_head::m_db is already normalized. There are no changes in here.
      
      - The initialization phase of sp_head when creating sp_head::m_qname
        now calls make_qname() with casedn_name=true,
        so sp_head::m_name gets written to sp_head::m_qname in lower case.
      
      - sp_cache_lookup() now also calls make_qname() with casedn_name=true,
        so sp_head::m_name gets written to the temporary lookup key in lower case.
      
      - sp_cache::m_hashtable now uses case sensitive comparison
      9695974e
    • Alexander Barkov's avatar
      MDEV-33019 The database part is not case sensitive in SP names · 916caac2
      Alexander Barkov authored
      Part#1 A non-functional change
      
      Changing the signature of Identifier_chain2::make_qname() from
      
        bool make_qname(MEM_ROOT *mem_root, LEX_CSTRING *dst) const;
      
      to
      
        LEX_CSTRING make_qname(MEM_ROOT *mem_root) const;
      
      Now the result is returned as LEX_CSTRING from the function rather than
      is passed as a parameter.
      The return value {NULL,0} means "EOM".
      916caac2
    • Alexander Barkov's avatar
      A 11.3->10.4 backport for MDEV-31991 Split class Database_qualified_name · 371bf4ab
      Alexander Barkov authored
      This is a requirement step to fix and merge easier
        MDEV-33019 The database part is not case sensitive in SP names
      
      The original MDEV-31991 commit commend:
      
      - Moving some of Database_qualified_name methods into a new class
        Identifier_chain2.
      
      - Changing the data type of the following variables from
        Database_qualified_name to Identifier_chain2:
      
        * q_pkg_proc in LEX::call_statement_start()
        * q_pkg_func in LEX::make_item_func_call_generic()
      
      Rationale:
      
      The data type of Database_qualified_name::m_db will be changed
      to Lex_ident_db soon. So Database_qualified_name won't be able
      to store the `pkg.routine` part of `db.pkg.routine` any more,
      because `pkg` must not depend on lower-case-table-names.
      371bf4ab
  5. 23 Dec, 2023 1 commit
  6. 22 Dec, 2023 1 commit
  7. 21 Dec, 2023 6 commits
  8. 20 Dec, 2023 6 commits
  9. 19 Dec, 2023 4 commits
  10. 15 Dec, 2023 3 commits
  11. 14 Dec, 2023 2 commits
  12. 13 Dec, 2023 4 commits
    • Marko Mäkelä's avatar
      MDEV-21245 InnoDB: Using a partial-field key prefix in search · 852e1383
      Marko Mäkelä authored
      ha_innobase::compare_key_parts(): If a full column index is
      being replaced with a column prefix index, return Compare_keys::NotEqual.
      852e1383
    • Rex's avatar
      MDEV-31279 Crash when lateral derived is guaranteed to return no rows · b4712242
      Rex authored
      Consider this query
      SELECT t1.* FROM t1, (SELECT t2.b FROM t2 WHERE NOT EXISTS
      (SELECT 1 FROM t3) GROUP BY b) sq where sq.b = t1.a;
      
      If SELECT 1 FROM t3 is expensive, for example t3 has >
      thd->variables.expensive_subquery_limit, first evaluation is deferred to
      mysql_derived_fill().  There it is noted that, in the above case
       NOT EXISTS (SELECT 1 FROM t3) is constant and false.
      
      This causes the join variable zero_result_cause to be set to
      "Impossible WHERE noticed after reading const tables" and the handler
      for this join is never "opened" via handler::ha_open.
      
      When mysql_derived_fill() is called for the next group of results, this
      unopened handler is not taken into account.
      
      reviewed by Igor Babaev (igor@mariadb.com)
      b4712242
    • Marko Mäkelä's avatar
      MDEV-18322 Assertion "wrong page type" on instant ALTER TABLE · c17aca2f
      Marko Mäkelä authored
      row_ins_clust_index_entry_low(): Invoke btr_set_instant() in the same
      mini-transaction that has successfully inserted the metadata record.
      In this way, if inserting the metadata record fails before any
      undo log record was written for it, the index root page will remain
      consistent.
      
      innobase_instant_try(): Remove the btr_set_instant() call.
      
      Reviewed by: Thirunarayanan Balathandayuthapani
      Tested by: Matthias Leich
      c17aca2f
    • Daniel Black's avatar
      MDEV-32795: ALTER SEQUENCE IF NOT EXISTS non_existing_seq Errors rather than note · fbe604d8
      Daniel Black authored
      Like all IF NOT EXISTS syntax, a Note should be generated.
      
      The original commit of Seqeuences cleared the IF NOT EXISTS part
      in the sql/sql_yacc.yy with lex->create_info.init(). Without this
      bit set there was no way it could do anything other than error.
      
      To remedy this removal, the sql_yacc.yy components have been
      minimised as they where all set at the beginning of the ALTER.
      This way the opt_if_not_exists correctly set the IF_EXISTS flag.
      
      In MDEV-13005 (bb4dd70e) the error code changed, requiring
      ER_UNKNOWN_SEQUENCES to be handled in the function
      No_such_table_error_handler::handle_condition.
      fbe604d8
  13. 12 Dec, 2023 3 commits
    • Daniel Black's avatar
      MDEV-21587: disk.disk{_notembedded} test result · 7504985d
      Daniel Black authored
      Allow for a CI system to be almost out of space, or having so
      little use, that the Total space is the same as available or used.
      
      Thanks Otto Kekäläinen for the bug report and testing.
      7504985d
    • Sergei Glushchenko's avatar
      MDEV-20286 mariabackup fails when innodb_max_dirty_pages_pct contains a... · 6193d0ca
      Sergei Glushchenko authored
      MDEV-20286 mariabackup fails when innodb_max_dirty_pages_pct contains a fraction (is not an integer)
      
      This is a port of the Percona Server commit 5265f42e290573e9591f8ca28ab66afc051f89a3
      
      which is the same as their bug PXB-1807: xtrabackup does not accept fractional values for
      innodb_max_dirty_pages_pct
      
      Problem:
      
      Variable specified as double in MySQL server, but read as long in the
      xtrabackup. This causes xtrabackup to fail at startup when the value
      contains decimal point.
      
      Fix:
      
      Make xtrabackup to interpret the value as double to be compatible with
      server.
      6193d0ca
    • Marko Mäkelä's avatar
      MDEV-31000 Assertion failed on ALTER TABLE...page_compressed=1 · 68e7909b
      Marko Mäkelä authored
      ha_innobase::check_if_supported_inplace_alter(): On ALTER_OPTIONS,
      if innodb_file_per_table=1 and the table resides in the system tablespace,
      require that the table be rebuilt (and moved to an .ibd file).
      
      Reviewed by: Thirunarayanan Balathandayuthapani
      Tested by: Matthias Leich
      68e7909b