1. 05 Nov, 2022 1 commit
    • Vladislav Vaintroub's avatar
      MDEV-29951 server hang in crash handler · 92be8d20
      Vladislav Vaintroub authored
      When trying to output stacktrace, and addr2line is not installed, the
      child process forked by start_addr2line_fork() will fail to do exec(),
      and finish with exit(1).
      
      There is a problem with exit() though - it runs exit handlers,
      and for the forked copy of crashing process, it is a bad idea.
      
      In 10.5+ code for example, exit handlers include
      tpool::task_group static destructors, and it will hang infinitely
      waiting for completion of the outstanding tasks.
      
      The fix is to use _exit() instead, which skips the execution of exit
      handlers
      92be8d20
  2. 03 Nov, 2022 1 commit
  3. 30 Oct, 2022 1 commit
    • Brad Smith's avatar
      Fix warning with signal typedef for *BSD · 7d96cb47
      Brad Smith authored
      /usr/ports/pobj/mariadb-10.9.3/mariadb-10.9.3/mysys/my_lock.c:183:7: warning: incompatible function pointer types assigning to 'sig_return' (aka 'void (*)(void)') from 'void (*)(int)' [-Wincompatible-function-pointer-types]
            ALARM_INIT;
            ^~~~~~~~~~
      /usr/ports/pobj/mariadb-10.9.3/mariadb-10.9.3/include/my_alarm.h:43:16: note: expanded from macro 'ALARM_INIT'
                              alarm_signal=signal(SIGALRM,my_set_alarm_variable);
                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      /usr/ports/pobj/mariadb-10.9.3/mariadb-10.9.3/mysys/my_lock.c:189:7: warning: incompatible function pointer types passing 'sig_return' (aka 'void (*)(void)') to parameter of type 'void (*)(int)' [-Wincompatible-function-pointer-types]
            ALARM_END;
            ^~~~~~~~~
      /usr/ports/pobj/mariadb-10.9.3/mariadb-10.9.3/include/my_alarm.h:44:41: note: expanded from macro 'ALARM_END'
                                                    ^~~~~~~~~~~~
      /usr/include/sys/signal.h:199:27: note: passing argument to parameter here
      void    (*signal(int, void (*)(int)))(int);
                                   ^
      2 warnings generated.
      
      The prototype is the same for all of the *BSD's.
      
      void
      (*signal(int sigcatch, void (*func)(int sigraised)))(int);
      7d96cb47
  4. 28 Oct, 2022 1 commit
  5. 27 Oct, 2022 1 commit
  6. 26 Oct, 2022 3 commits
  7. 25 Oct, 2022 5 commits
  8. 24 Oct, 2022 4 commits
  9. 22 Oct, 2022 8 commits
  10. 21 Oct, 2022 5 commits
  11. 19 Oct, 2022 4 commits
  12. 18 Oct, 2022 3 commits
    • Daniel Black's avatar
      MDEV-29540 Incorrect sequence values in INSERT SELECT · 8c389393
      Daniel Black authored
      The population of default values in INSERT SELECT was being
      performed twice. With sequences, this resulted in every
      second sequence value being used.
      
      With SELECT INSERT we remove the second invokation of
      table->update_default_fields(). This was already performed
      in store_values() invoking fill_record_n_invoke_before_triggers()
      which invoked update_default_fields() previously.
      
      We do need to return an error on duplicate values, so the
      ::store_values is extended to take the ignore option.
      8c389393
    • Marko Mäkelä's avatar
    • Anel Husakovic's avatar
      MDEV-28455: CREATE TEMPORARY TABLES privilege is insufficient for SHOW COLUMNS · 64f822c1
      Anel Husakovic authored
      =========== Problem =============
      - `show columns` is not working for temporary tables, even though there
      is enough privilege `create temporary tables`.
      =========== Solution =============
      - Append `TMP_TABLE_ACLS` privilege when running `show columns` for temp
      tables.
      - Additionally `check_access()` for database only once, not for each
      field
      =========== Additionally =============
      - Update comments for function `check_table_access` arguments
      
      Reviewed by: <vicentiu@mariadb.org>
      64f822c1
  13. 17 Oct, 2022 1 commit
    • Dmitry Shulga's avatar
      MDEV-16128: Server crash in Item_func::print_op on 2nd execution of PS · bd9274fa
      Dmitry Shulga authored
      For some queries that involve tables with different but convertible
      character sets for columns taking part in the query, repeatable
      execution of such queries in PS mode or as part of a stored routine
      would result in server abnormal termination.
      
      For example,
        CREATE TABLE t1 (a2 varchar(10));
        CREATE TABLE t2 (u1 varchar(10) CHARACTER SET utf8);
        CREATE TABLE t3 (u2 varchar(10) CHARACTER SET utf8);
        PREPARE stmt FROM
          "SELECT t1.* FROM (t1 JOIN t2 ON (t2.u1 = t1.a2))
           WHERE (EXISTS (SELECT 1 FROM t3 WHERE t3.u2 = t1.a2))";
      
        EXECUTE stmt;
        EXECUTE stmt; <== Running this prepared statement the second time
                          results in server crash.
      
      The reason of server crash is that an instance of the class
      Item_func_conv_charset, that created for conversion of a column
      from one character set to another, is allocated on execution
      memory root but pointer to this instance is stored in an item
      placed on prepared statement memory root. Below is calls trace to
      the place where an instance of the class Item_func_conv_charset
      is created.
      
      setup_conds
       Item_func::fix_fields
        Item_bool_rowready_func2::fix_length_and_dec
         Item_func::setup_args_and_comparator
          Item_func_or_sum::agg_arg_charsets_for_comparison
           Item_func_or_sum::agg_arg_charsets
            Item_func_or_sum::agg_item_set_converter
             Item::safe_charset_converter
      
      And the following trace shows the place where a pointer to
      the instance of the class Item_func_conv_charset is passed
      to the class Item_func_eq, that is created on a memory root of
      the prepared statement.
      
      Prepared_statement::execute
       mysql_execute_command
        execute_sqlcom_select
         handle_select
          mysql_select
           JOIN::optimize
            JOIN::optimize_inner
             convert_join_subqueries_to_semijoins
              convert_subq_to_sj
      
      To fix the issue, switch to the Prepared Statement memory root
      before calling the method Item_func::setup_args_and_comparator
      in order to place any created Items on permanent memory root.
      It may seem that such approach would result in a memory
      leakage in case the parameter marker '?' is used in the query
      as in the following example
        PREPARE stmt FROM
          "SELECT t1.* FROM (t1 JOIN t2 ON (t2.u1 = t1.a2))
           WHERE (EXISTS (SELECT 1 FROM t3 WHERE t3.u2 = ?))";
        EXECUTE stmt USING convert('A' using latin1);
      but it wouldn't since for such case any of the parameter markers
      is treated as a constant and no subquery to semijoin optimization
      is performed.
      bd9274fa
  14. 16 Oct, 2022 2 commits
    • Oleksandr Byelkin's avatar
      new 3.1 · 4b92fedc
      Oleksandr Byelkin authored
      4b92fedc
    • Anel's avatar
      Update ODBC instructions for Connect SE and update ODBC result file (#2284) · b20f608d
      Anel authored
      * ODBC Connect cosmetic fixes
      
      - Update command for connection for default `peer` authentication for user
      `postgres` (unless changed in `pg_hba.conf`).
      - Update command for privilege to be more verbose.
      - Update path for `.sql` file
      - Update instructions for `pg_hba.conf` file to use unix socket
      (`local`) type as well as TCP/IP type `host`.
      - Update instruction about usage of user dsn (data source file) over
      system dsn.
      - Update path of `odbc-postgresql` driver path in comment
      
      * Connect SE: update ODBC result file
      b20f608d