1. 26 Jan, 2022 2 commits
    • Alexey Botchkov's avatar
      MDEV-20770 Server crashes in JOIN::transform_in_predicates_into_in_subq upon... · 020dc54d
      Alexey Botchkov authored
      MDEV-20770 Server crashes in JOIN::transform_in_predicates_into_in_subq upon 2nd execution of PS/SP comparing GEOMETRY with other types.
      
      The Item_in_subselect::in_strategy keeps the value and as the error
      happens the condition isn't modified. That leads to wrong ::fix_fields
      execution on second PS run. Also the select->table_list is merged
      but not restored if an error happens, which causes hanging loops on
      the third PS execution.
      020dc54d
    • Igor Babaev's avatar
      MDEV-27510 Query returns wrong result when using split optimization · 00412656
      Igor Babaev authored
      This bug may affect the queries that uses a grouping derived table with
      grouping list containing references to columns from different tables if
      the optimizer decides to employ the split optimization for the derived
      table. In some very specific cases it may affect queries with a grouping
      derived table that refers only one base table.
      This bug was caused by an improper fix for the bug MDEV-25128. The fix
      tried to get rid of the equality conditions pushed into the where clause
      of the grouping derived table T to which the split optimization had been
      applied. The fix erroneously assumed that only those pushed equalities
      that were used for ref access of the tables referenced by T were needed.
      In fact the function remove_const() that figures out what columns from the
      group list can be removed if the split optimization is applied can uses
      other pushed equalities as well.
      This patch actually provides a proper fix for MDEV-25128. Rather than
      trying to remove invalid pushed equalities referencing the fields of SJM
      tables with a look-up access the patch attempts not to push such equalities.
      
      Approved by Oleksandr Byelkin <sanja@mariadb.com>
      00412656
  2. 25 Jan, 2022 1 commit
  3. 20 Jan, 2022 1 commit
  4. 19 Jan, 2022 2 commits
    • Sergei Petrunia's avatar
      MDEV-26249: Crash in Explain_node::print_explain_for_children with slow query log · 7922fbf7
      Sergei Petrunia authored
      The problem affected queries in form:
      
        SELECT FROM (SELECT where Split Materialized is applicable) WHERE 1=0
      
      The problem was caused by this:
      - The select in derived table uses two-phase optimization (due to a
        possible Split Materialized).
      - The primary select has "Impossible where" and so it short-cuts its
        optimization.
      - The optimization for the SELECT in the derived table is never finished,
        and EXPLAIN data structure has a dangling pointer to select #2.
      
      Fixed with this: make JOIN::optimize_stage2() invoke optimization of
      derived tables when it is handing a degenerate JOIN with zero tables.
      We will not execute the derived tables but we need their query plans
      for [SHOW]EXPLAIN.
      7922fbf7
    • Monty's avatar
      Updated rocksdb.corrupted_data_reads_debug result file · dfbfd39e
      Monty authored
      The change was because of new rocksdb error message.
      dfbfd39e
  5. 18 Jan, 2022 1 commit
    • Igor Babaev's avatar
      MDEV-27132 Wrong result from query when using split optimization · 97425f74
      Igor Babaev authored
      This bug could affect queries with a grouping derived table containing
      equalities in the where clause of its specification if the optimizer
      chose to apply split optimization to access the derived table. In such
      cases wrong results could be returned from the queries.
      When the optimizer considers a possibility of using split optimization
      to a derived table it injects equalities joining the derived table with
      other tables into the where condition of the derived table. After the join
      order for the execution using split optimization has been chosen as the
      cheapest the injected equalities that are not used to access the derived
      table are removed from the where condition of the derived table.
      For this removal the optimizer looks through the conjuncts of the where
      condition of the derived table, fetches the equalities and checks whether
      they belong to the list of injected equalities.
      As the injection of the list was performed just by the insertion of it
      into the list of top level AND condition of the where condition some extra
      conjuncts from the where condition could be automatically attached to the
      end of the list of injected equalities. If such attached conjunct happened
      to be an equality predicate it was removed from the where condition of the
      derived table and thus lost for checking at the execution phase.
      The bug has been fixed by injecting of a shallow copy of the list of the
      pushed equalities rather than the list itself leaving the latter intact.
      
      Approved by Oleksandr Byelkin <sanja@mariadb.com>
      97425f74
  6. 15 Jan, 2022 1 commit
  7. 14 Jan, 2022 1 commit
  8. 13 Jan, 2022 6 commits
    • Aleksey Midenkov's avatar
      MDEV-27452 TIMESTAMP(0) system field is allowed for certain creation of system-versioned table · 585cb18e
      Aleksey Midenkov authored
      First, we do not add VERS_UPDATE_UNVERSIONED_FLAG for system field and
      that fixes SHOW CREATE result.
      
      Second, we have to call check_sys_fields() for any CREATE TABLE and
      there correct type is checked for system fields.
      
      Third, we update system_time like as_row structures for ALTER TABLE
      and that makes check_sys_fields() happy for ALTER TABLE when we make
      system fields hidden.
      585cb18e
    • Aleksey Midenkov's avatar
      MDEV-26778 row_start is not updated in current row for InnoDB · 241ac79e
      Aleksey Midenkov authored
      Update was skipped (need_update was false) because compare_record()
      used HA_PARTIAL_COLUMN_READ branch and it skipped row_start check
      has_explicit_value() was false. When we set bit for row_start in
      has_value_set the row is updated with new row_start value.
      
      The bug was caused by combination of MDEV-23446 and 3789692d. The
      latter one says:
      
        ... But generated columns that are written to the table are always
        deterministic and cannot change unless normal non-generated columns
        were changed. ...
      
      Since MDEV-23446 generated row_start can change while non-generated
      columns are not changed.
      
      Explicit value flag came from HAS_EXPLICIT_DEFAULT which was used to
      distinguish default-generated value from user-supplied one.
      241ac79e
    • Aleksey Midenkov's avatar
      MDEV-27217 ha_partition::start_stmt() ignored error fix · 7c61fb2f
      Aleksey Midenkov authored
      ha_partition::start_stmt() continued processing in error state. Though
      no known bug cases yet it seems break was made incorrect by
      f93a2a3b (2016) while originally break was ok since cd483c55
      (2005).
      7c61fb2f
    • Aleksey Midenkov's avatar
      MDEV-27217 DELETE partition selection doesn't work for history partitions · 4d5ae2b3
      Aleksey Midenkov authored
      LIMIT history switching requires the number of history partitions to
      be marked for read: from first to last non-empty plus one empty. The
      least we can do is to fail with error message if the needed partition
      was not marked for read. As this is handler interface we require new
      handler error code to display user-friendly error message.
      
      Switching by INTERVAL works out-of-the-box with
      ER_ROW_DOES_NOT_MATCH_GIVEN_PARTITION_SET error.
      4d5ae2b3
    • Aleksey Midenkov's avatar
      Versioning test suite cleanups · f9f6b190
      Aleksey Midenkov authored
      Merged truncate_privilege and sysvars-notembedded into not_embedded.test
      Merged partition_innodb into trx_id.test
      f9f6b190
    • Sergei Petrunia's avatar
      MDEV-26337: subquery with groupby and ROLLUP returns incorrect results on LEFT... · c04adce8
      Sergei Petrunia authored
      MDEV-26337: subquery with groupby and ROLLUP returns incorrect results on LEFT JOIN on INDEXED values
      
      Disable LATERAL DERIVED optimization for subqueries that have WITH ROLLUP.
      
      This bug could affect queries with grouping derived tables / views / CTEs
      with ROLLUP. The bug could manifest itself if the corresponding
      materialized derived tables are subject to split optimization.
      
      The current implementation of the split optimization produces rows
      from the derived table in an arbitrary order. So these rows must be
      accumulated in another temporary table and sorted according to the
      used GROUP BY clause in order to be able to generate the additional
      ROLLUP rows.
      
      This patch prohibits to use split optimization for grouping derived
      tables / views / CTEs with ROLLUP.
      c04adce8
  9. 07 Jan, 2022 1 commit
    • Tuukka Pasanen's avatar
      MDEV-26317: Add SYSTEMD_READWRITEPATH variable to mariadb.service.in-file · 25f598f5
      Tuukka Pasanen authored
      Add SYSTEMD_READWRITEPATH-variable to mariadb{@,}.service.in to make sure that
      if one is not building RPM or DEB packages then make sure there is ReadWritePaths
      directive is defined in systemd service file.
      
      This ensures that tar-ball installation has permissions to write database default
      installation path (default: /usr/local/mysql/data) even if it's located
      under /usr. Writing to that location is prevented by 'ProtectSystem=full'
      systemd directive by default.
      
      Prefixing the path with "-" in systemd causes there to not be an error if the
      path doesn't exist. This may occur if the user has configured a datadir
      elsewhere.
      
      Reviewer: Daniel Black
      25f598f5
  10. 03 Jan, 2022 1 commit
    • Andrei's avatar
      MDEV-27365 CREATE-or-REPLACE SEQUENCE is binlogged without DDL flag · 80da35a3
      Andrei authored
      CREATE-OR-REPLACE SEQUENCE is not logged with Gtid event DDL flag
      which affects its slave parallel execution.
      Unlike other DDL:s it can occur in concurrent execution with following transactions
      which can lead to various errors, including asserts like
      
      (mdl_request->type != MDL_INTENTION_EXCLUSIVE && mdl_request->type != MDL_EXCLUSIVE) || !(get_thd()->rgi_slave && get_thd()->rgi_slave->is_parallel_exec && lock->check_if_conflicting_replication_locks(this)
      
      in MDL_context::acquire_lock.
      
      Fixed to wrap internal statement level commit with save-
      and-restore of TRANS_THD::m_unsafe_rollback_flags.
      80da35a3
  11. 30 Dec, 2021 1 commit
  12. 24 Dec, 2021 1 commit
  13. 23 Dec, 2021 2 commits
    • Julius Goryavsky's avatar
      MDEV-24097: galera[_3nodes] suite tests in MTR sporadically fails · b5cbe506
      Julius Goryavsky authored
      This is the first part of the fixes for MDEV-24097. This commit
      contains the fixes for instability when testing Galera and when
      restarting nodes quickly:
      
      1) Protection against a "stuck" old SST process during the execution
         of the new SST (after restarting the node) is now implemented for
         mariabackup / xtrabackup, which should help to avoid almost all
         conflicts due to the use of the same ports - both during testing
         with mtr, so and when restarting nodes quickly in a production
         environment.
      2) Added more protection to scripts against unexpected return of
         the rc != 0 (in the commands for deleting temporary files, etc).
      3) Added protection against unexpected crashes during binlog transfer
         (in SST scripts for rsync).
      4) Spaces and some special characters in binlog filenames shouldn't
         be a problem now (at the script level).
      5) Daemon process termination tracking has been made more robust
         against crashes due to unexpected termination of the previous SST
         process while new scripts are running.
      6) Reading ssl encryption parameters has been moved from specific
         SST scripts to a common wsrep_sst_common.sh script, which allows
         unified error handling, unified diagnostics and simplifies script
         revisions in the future.
      7) Improved diagnostics of errors related to the use of openssl.
      8) Corrections have been made for xtrabackup-v2 (both in tests and in
         the script code) that restore the work of xtrabackup with updated
         versions of innodb.
      9) Fixed some tests for galera_3nodes, although the complete solution
         for the problem of starting three nodes at the same time on fast
         machines will be done in a separate commit.
      
      No additional tests are required as this commit fixes problems with
      existing tests.
      b5cbe506
    • Julius Goryavsky's avatar
      Merge branch 10.2 into 10.3 · 3376668c
      Julius Goryavsky authored
      3376668c
  14. 22 Dec, 2021 2 commits
    • Daniel Black's avatar
      MDEV-23175: my_timer_milliseconds clock_gettime for multiple platfomrs · 12087d67
      Daniel Black authored
      Small postfix to MDEV-23175 to ensure faster option on FreeBSD
      and compatibility to Solaris that isn't high resolution.
      
      ftime is left as a backup in case an implementation doesn't
      contain any of these clocks.
      
      FreeBSD
          $ ./unittest/mysys/my_rdtsc-t
          1..11
          # ----- Routine ---------------
          # myt.cycles.routine          :             5
          # myt.nanoseconds.routine     :            11
          # myt.microseconds.routine    :            13
          # myt.milliseconds.routine    :            11
          # myt.ticks.routine           :            17
          # ----- Frequency -------------
          # myt.cycles.frequency        :    3610295566
          # myt.nanoseconds.frequency   :    1000000000
          # myt.microseconds.frequency  :       1000000
          # myt.milliseconds.frequency  :           899
          # myt.ticks.frequency         :           136
          # ----- Resolution ------------
          # myt.cycles.resolution       :             1
          # myt.nanoseconds.resolution  :             1
          # myt.microseconds.resolution :             1
          # myt.milliseconds.resolution :             7
          # myt.ticks.resolution        :             1
          # ----- Overhead --------------
          # myt.cycles.overhead         :            26
          # myt.nanoseconds.overhead    :         19140
          # myt.microseconds.overhead   :         19036
          # myt.milliseconds.overhead   :           578
          # myt.ticks.overhead          :         21544
          ok 1 - my_timer_init() did not crash
          ok 2 - The cycle timer is strictly increasing
          ok 3 - The cycle timer is implemented
          ok 4 - The nanosecond timer is increasing
          ok 5 - The nanosecond timer is implemented
          ok 6 - The microsecond timer is increasing
          ok 7 - The microsecond timer is implemented
          ok 8 - The millisecond timer is increasing
          ok 9 - The millisecond timer is implemented
          ok 10 - The tick timer is increasing
          ok 11 - The tick timer is implemented
      12087d67
    • Alexander Barkov's avatar
      MDEV-27195 SIGSEGV in Table_scope_and_contents_source_st::vers_check_system_fields · a5ef74e7
      Alexander Barkov authored
      The old code erroneously used default_charset_info to compare field names.
      default_charset_info can point to any arbitrary collation,
      including ucs2*, utf16*, utf32*, including those that do not
      support strcasecmp().
      
      my_charset_utf8mb4_unicode_ci, which is used in this scenario:
      
      CREATE TABLE t1 ENGINE=InnoDB WITH SYSTEM VERSIONING AS SELECT 0;
      
      does not support strcasecmp().
      
      Fixing the code to use Lex_ident::streq(), which uses
      system_charset_info instead of default_charset_info.
      a5ef74e7
  15. 21 Dec, 2021 1 commit
    • Marko Mäkelä's avatar
      MDEV-27332 SIGSEGV in fetch_data_into_cache() · 3b33593f
      Marko Mäkelä authored
      Since commit fb335b48 we may have
      a null pointer in purge_sys.query when fetch_data_into_cache() is
      invoked and innodb_force_recovery>4. This is because the call to
      purge_sys.create() would be skipped.
      
      fetch_data_into_cache(): Load the purge_sys pseudo transaction pointer
      to a local variable (null pointer if purge_sys is not initialized).
      3b33593f
  16. 17 Dec, 2021 1 commit
  17. 16 Dec, 2021 3 commits
    • Aleksey Midenkov's avatar
      MDEV-27244 Table corruption upon adding serial data type · 3fd80d08
      Aleksey Midenkov authored
      MDEV-25803 excluded some cases from key sort upon alter table. That
      particularly depends on ALTER_ADD_INDEX flag. Creating a column of
      SERIAL data type missed that flag. Though equivalent operation
      
        alter table t1 add x bigint unsigned not null auto_increment unique;
      
      has ALTER_ADD_INDEX flag.
      3fd80d08
    • Dmitry Shulga's avatar
      MDEV-23182: Server crashes in Item::fix_fields_if_needed /... · a65d01a4
      Dmitry Shulga authored
      MDEV-23182: Server crashes in Item::fix_fields_if_needed / table_value_constr::prepare upon 2nd execution of PS
      
      Repeating execution of a query containing the clause IN with string literals
      in environment where the server variable in_predicate_conversion_threshold
      is set results in server abnormal termination in case the query is run
      as a Prepared Statement and conversion of charsets for string values in the
      query are required.
      
      The reason for server abnormal termination is that instances of the class
      Item_string created on transforming the IN clause into subquery were created
      on runtime memory root that is deallocated on finishing execution of Prepared
      statement. On the other hand, references to Items placed on deallocated memory
      root still exist in objects of the class table_value_constr. Subsequent running
      of the same prepared statement leads to dereferencing of pointers to already
      deallocated memory that could lead to undefined behaviour.
      
      To fix the issue the values being pushed into a values list for TVC are created
      by cloning their original items. This way the cloned items are allocate on
      the PS memroot and as consequences no dangling pointer does more exist.
      a65d01a4
    • Dmitry Shulga's avatar
      MDEV-21866: Assertion `!result' failed in convert_const_to_int upon 2nd execution of PS · fff8ac2e
      Dmitry Shulga authored
      Consider the following use case:
      MariaDB [test]> CREATE TABLE t1 (field1 BIGINT DEFAULT -1);
      MariaDB [test]> CREATE VIEW v1 AS SELECT DISTINCT field1 FROM t1;
      
      Repeated execution of the following query as a Prepared Statement
      
      MariaDB [test]> PREPARE stmt FROM 'SELECT * FROM v1 WHERE field1 <=> NULL';
      MariaDB [test]> EXECUTE stmt;
      
      results in a crash for a server built with DEBUG.
      
      MariaDB [test]> EXECUTE stmt;
      ERROR 2013 (HY000): Lost connection to MySQL server during query
      
      Assertion failed: (!result), function convert_const_to_int, file item_cmpfunc.cc, line 476.
      Abort trap: 6 (core dumped)
      
      The crash inside the function convert_const_to_int() happens by the reason
      that the value -1 is stored in an instance of the class Field_longlong
      on restoring its original value in the statement
        result= field->store(orig_field_val, TRUE);
      that leads to assigning the value 1 to the variable 'result' with subsequent
      crash in the DBUG_ASSERT statement following it
        DBUG_ASSERT(!result);
      
      The main matter here is why this assertion failure happens on the second
      execution of the prepared statement and doens't on the first one.
      On first handling of the statement
        'EXECUTE stmt;'
      a temporary table is created for serving the query involving the view 'v1'.
      The table is created by the function create_tmp_table() in the following
      calls trace: (trace #1)
        JOIN::prepare (at sql_select.cc:725)
          st_select_lex::handle_derived
            LEX::handle_list_of_derived
              TABLE_LIST::handle_derived
                mysql_handle_single_derived
                  mysql_derived_prepare
                    select_union::create_result_table
                      create_tmp_table
      
      Note, that the data member TABLE::status of a TABLE instance returned by the
      function create_tmp_table() has the value 0.
      
      Later the function setup_table_map() is called on the TABLE instance just
      created for the sake of the temporary table (calls trace #2 is below):
        JOIN::prepare (at sql_select.cc:737)
          setup_tables_and_check_access
            setup_tables
              setup_table_map
      where the data member TABLE::status is set to the value STATUS_NO_RECORD.
      
      After that when execution of the method JOIN::prepare reaches calling of
      the function setup_without_group() the following calls trace is invoked
        JOIN::prepare
          setup_without_group
            setup_conds
              Item_func::fix_fields
                Item_func_equal::fix_length_and_dec
                  Item_bool_rowready_func2::fix_length_and_dec
                    Item_func::setup_args_and_comparator
                      Item_func::convert_const_compared_to_int_field
                        convert_const_to_int
      
      There is the following code snippet in the function convert_const_to_int()
      at the line item_cmpfunc.cc:448
          bool save_field_value= (field_item->const_item() ||
                                  !(field->table->status & STATUS_NO_RECORD));
      Since field->table->status has bits STATUS_NO_RECORD set the variable
      save_field_value is false and therefore neither the method
      Field_longlong::val_int() nor the method Field_longlong::store is called
      on the Field instance that has the numeric value -1.
      That is the reason why first execution of the Prepared Statement for the query
        'SELECT * FROM v1 WHERE field1 <=> NULL'
      is successful.
      
      On second running of the statement 'EXECUTE stmt' a new temporary tables
      is also created by running the calls trace #1 but the trace #2 is not executed
      by the reason that data member SELECT_LEX::first_cond_optimization has been set
      to false on first execution of the prepared statemet (in the method
      JOIN::optimize_inner()). As a consequence, the data member TABLE::status for
      a temporary table just created doesn't have the flags STATUS_NO_RECORD set and
      therefore on re-execution of the prepared statement the methods
      Field_longlong::val_int() and Field_longlong::store() are called for the field
      having the value -1 and the DBUG_ASSERT(!result) is fired.
      
      To fix the issue the data member TABLE::status has to be assigned the value
      STATUS_NO_RECORD in every place where the macros empty_record() is called
      to emptify a record for just instantiated TABLE object created on behalf
      the new temporary table.
      fff8ac2e
  18. 15 Dec, 2021 3 commits
  19. 14 Dec, 2021 2 commits
    • Julius Goryavsky's avatar
      MDEV-27181: Galera SST scripts should use ssl_capath for CA directory · 7bc629a5
      Julius Goryavsky authored
      1. Galera SST scripts should use ssl_capath (not ssl_ca) for CA
         directory. The current implementation tries to automatically
         detect the path using the trailing slash in the ssl_ca variable
         value, but this approach is not compatible with the server
         configuration. Now, by analogy with the server, SST scripts
         also use a separate ssl_capath variable. In addition, a similar
         tcapath variable has been added for the old-style configuration
         (in the "sst" section).
      2. Openssl utility detection made more reliable.
      3. Removed extra spaces in automatically generated command lines -
         to simplify debugging of the SST scripts.
      4. In general, the code for detecting the presence or absence of
         auxiliary utilities has been improved - it is made more reliable
         in some configurations (and for shells other than bash).
      7bc629a5
    • Julius Goryavsky's avatar
      MDEV-27181: Galera SST scripts should use ssl_capath for CA directory · 8bb55633
      Julius Goryavsky authored
      1. Galera SST scripts should use ssl_capath (not ssl_ca) for CA
         directory. The current implementation tries to automatically
         detect the path using the trailing slash in the ssl_ca variable
         value, but this approach is not compatible with the server
         configuration. Now, by analogy with the server, SST scripts
         also use a separate ssl_capath variable. In addition, a similar
         tcapath variable has been added for the old-style configuration
         (in the "sst" section).
      2. Openssl utility detection made more reliable.
      3. Removed extra spaces in automatically generated command lines -
         to simplify debugging of the SST scripts.
      4. In general, the code for detecting the presence or absence of
         auxiliary utilities has been improved - it is made more reliable
         in some configurations (and for shells other than bash).
      8bb55633
  20. 13 Dec, 2021 1 commit
  21. 10 Dec, 2021 1 commit
  22. 09 Dec, 2021 1 commit
  23. 07 Dec, 2021 4 commits