1. 27 Jul, 2022 4 commits
    • Marko Mäkelä's avatar
      Merge 10.3 into 10.4 · e5c4f4e5
      Marko Mäkelä authored
      e5c4f4e5
    • Marko Mäkelä's avatar
      MDEV-28495 InnoDB corruption due to lack of file locking · 0ee1082b
      Marko Mäkelä authored
      Starting with commit da094188 (MDEV-24393),
      MariaDB will no longer acquire advisory file locks on InnoDB data
      files by default, because it would create a large number of
      entries in Linux /proc/locks.
      
      The motivation for acquiring the file locks is to prevent accidental
      concurrent startup of multiple server processes on the same data files.
      Such mistake still turns out to be relatively common, based on
      corruption bug reports from the community.
      
      To prevent corruption due to concurrent startup attempts, the
      Aria storage engine would unconditionally acquire an advisory lock
      on one of its log files.
      
      Solution: InnoDB will always lock its system tablespace files.
      (Ever since commit 685d958e
      the InnoDB log file will not necessarily be open while the
      server is running, because it can be accessed via memory-mapped I/O.)
      
      If more protection is desired, then the option --external-locking
      can be used.
      
      The mandatory advisory lock also fixes intermittent failures of
      some crash recovery tests. It turns out that when the mtr test harness
      kills and restarts the server, it will not actually ensure that the
      old process has terminated before starting the new one.
      0ee1082b
    • Oleksandr Byelkin's avatar
      Merge branch '10.3' into 10.4 · 3bb36e94
      Oleksandr Byelkin authored
      3bb36e94
    • Igor Babaev's avatar
      MDEV-29139 Crash when using ANY predicand with redundant subquery in GROUP BY clause · bd935a41
      Igor Babaev authored
      This bug could cause a crash of the server when executing queries containing
      ANY/ALL predicands with redundant subqueries in GROUP BY clauses.
      These subqueries are eliminated by remove_redundant_subquery_clause()
      together with elimination of GROUP BY list containing these subqueries.
      However the references to the elements of the GROUP BY remained in the
      JOIN::all_fields list of the right operand of of the ALL/ANY predicand.
      Later these references confused make_aggr_tables_info() when forming
      proper execution structures after ALL/ANY predicands had been replaced
      with expressions containing MIN/MAX set functions.
      The patch just removes these references from JOIN::all_fields list used
      by the subquery of the ALL/ANY predicand when its GROUP BY clause is
      eliminated.
      
      Approved by Oleksandr Byelkin <sanja@mariadb.com>
      bd935a41
  2. 26 Jul, 2022 11 commits
  3. 25 Jul, 2022 5 commits
    • Brandon Nesterenko's avatar
      MDEV-21087/MDEV-21433: ER_SLAVE_INCIDENT arrives at slave without failure specifics · 555c12a5
      Brandon Nesterenko authored
      Problem:
      =======
      
      This patch addresses two issues:
      
       1. An incident event can be incorrectly reported for transactions
      which are rolled back successfully. That is, an incident event
      should only be generated for failed “non-transactional transactions”
      (i.e., those which modify non-transactional tables) because they
      cannot be rolled back.
      
       2. When the mariadb slave (error) stops at receiving the incident
      event there's no description of what led to it. Neither in the event
      nor in the master's error log.
      
      Solution:
      ========
      
      Before reporting an incident event for a transaction, first validate
      that it is “non-transactional” (i.e. cannot be safely rolled back).
      To determine if a transaction is non-transactional,
        lex->stmt_accessed_table(LEX::STMT_WRITES_NON_TRANS_TABLE)
      is used because it is set previously in
      THD::decide_logging_format().
      
      Additionally, when an incident event is written, write an error
      message to the server’s error log to indicate the underlying issue.
      
      Reviewed by:
      ===========
      Andrei Elkin <andrei.elkin@mariadb.com>
      555c12a5
    • Rucha Deodhar's avatar
      This commit is a fixup for MDEV-28762 · 46ff6608
      Rucha Deodhar authored
      46ff6608
    • Marko Mäkelä's avatar
      Fix DBUG_ENTER/return mismatch · f1c8749f
      Marko Mäkelä authored
      Spotted by Thirunarayanan Balathandayuthapani.
      f1c8749f
    • Marko Mäkelä's avatar
      MDEV-28980 InnoDB: Failing assertion: len <= MAX_TABLE_NAME_LEN · 8aa37c26
      Marko Mäkelä authored
      dict_load_foreigns(): Use a correctly sized buffer for the maximum-length
      SYS_FOREIGN.ID. In case of overflow, do not crash the server but instead
      return DB_CORRUPTION.
      8aa37c26
    • Brad Smith's avatar
  4. 23 Jul, 2022 1 commit
  5. 22 Jul, 2022 3 commits
  6. 21 Jul, 2022 1 commit
  7. 20 Jul, 2022 1 commit
  8. 18 Jul, 2022 9 commits
    • Aleksey Midenkov's avatar
      MDEV-29023 MTR hangs after multiple failures · 18488048
      Aleksey Midenkov authored
      Passing $opt_parallel as $childs is wrong: child can be killed before
      it connects and you will never decrement $childs for this.
      
      Another problem is (and that is the cause of this bug): child can be
      killed and never close server socket. This can happen f.ex. after
      unmaskable KILL signal. In such case the socket is closed by reaping
      the child but that never happens inside reading the socket loop in
      run_test_server().
      
      The proper design is the waitless reap of children inside the socket
      loop and if there is no more children we finish the socket loop. Since
      there is Windows variation where we don't control the children via
      waitpid(), all the clients must normally close the socket and only
      this can finish the socket loop. For Unix variation we reckon that
      case as all children closed the socket but not all yet died and for
      that we do final waiting waitpid() (was done before the patch as
      well).
      
      To be more complete, we now handle 3 end-of-game scenarios in Unix:
      
         1. all children closed socket, all children died: everything is
            handled by the socket loop;
      
         2. all children closed socket, not all yet died: we wait for alive
            children to die after exiting the socket loop;
      
         3. not all children closed socket, all children died: everything is
            handled by the socket loop.
      
      For Windows end-of-game scenario is only one:
      
         All children close the socket.
      18488048
    • Aleksey Midenkov's avatar
      MDEV-29023 waitpid() cleanup · 7ca5c7d8
      Aleksey Midenkov authored
      The case for "Unknown process $ret_pid exited" is never known to be
      valid. Such state is not documented for waitpid().
      7ca5c7d8
    • Aleksey Midenkov's avatar
    • Aleksey Midenkov's avatar
    • Aleksey Midenkov's avatar
      MDEV-28931 MTR prints detailed stack trace unconditionally · e9be5428
      Aleksey Midenkov authored
      66832e3a introduced change that prints core dumps in very detailed
      format. That's completely out of user-friendliness but serves as a
      measure for debugging hard-reproducible bugs.
      
      The proper way to implement this:
      
        1. it must be controlled by command-line and environment variable;
        2. detailed traces must be default for buildbots only, for user
           invocations normal stack traces should be printed.
      
      Options for control are: MTR_PRINT_CORE and --print-core that accept
      the following values:
      
        no	         Don't print core
        short	       	 Print stack trace of failed thread
        medium	 Print stack traces of all threads
        detailed       Print all stack traces with debug context
        custom:<code>  Use debugger commands <code> to print stack trace
      
      Default setting is: short (see env_or_default() call in pre_setup())
      
      For environment variable wrong values are silently ignored (falls back
      to default setting, see env_or_default()).
      
      Command-line option --print-core (or -C) overrides environment
      variable. Its default value is 'short' if not specified explicitly
      (same env_or_default() call in pre_setup()). Explicit values are
      checked for validity.
      
      --print-method option can specify by which debugger we print
      cores. For Windows there is only one choice: cdb. For Unix the values
      are: gdb, dbx, lldb, auto. Default value is: auto
      
      In 'auto' we try to use all possible debuggers until success.
      e9be5428
    • Aleksey Midenkov's avatar
      MDEV-28931 Debugger.pm readability fix · 220fb679
      Aleksey Midenkov authored
      setup_boot_args(), setup_client_args(), setup_args() traversing
      datastructures on each invocation. Even if performance is not
      important to perl script (though it definitely saves some CO2), this
      nonetheless provokes some code-reading questions. Reading and
      debugging such code is not convenient.
      
      The better way is to prepare all the data in advance in an easily
      readable form as well as do the validation step before any further
      processing.
      
      Use mtr_report() instead of die() like the other code does.
      
      TODO: do_args() does even more data processing magic. Prepare that
      data according the above strategy in advance in pre_setup() if possible.
      220fb679
    • Aleksey Midenkov's avatar
      MDEV-28931 --verbose option is too verbose · ce7820eb
      Aleksey Midenkov authored
      GetOpt::Long bundling option for convenient one-char verbosity levels:
      
        -v    General verbosity (file and execute operations)
        -vv   High verbosity (algorithmic considerations)
        -vvv  Debug verbosity (anything else)
      ce7820eb
    • Aleksey Midenkov's avatar
      MDEV-28931 Cleanup: try GDB to print core first · 83f7d25c
      Aleksey Midenkov authored
      Do we still need this Sun Studio hack?
      83f7d25c
    • Vladislav Vaintroub's avatar
      990ddaba
  9. 17 Jul, 2022 1 commit
  10. 16 Jul, 2022 1 commit
    • Alexey Botchkov's avatar
      MDEV-26546 SIGSEGV's in spider_db_connect on SHOW TABLE and spider_db…... · 8911823f
      Alexey Botchkov authored
      MDEV-26546 SIGSEGV's in spider_db_connect on SHOW TABLE and spider_db… …_mbase::connect (and SIGSEGV's in check_vcol_forward_refs and inline_mysql_mutex_lock)
      
      Not the SPIDER issue - happens to INSERT DELAYED.
      the field::make_new_field does't copy the LONG_UNIQUE_HASH_FIELD
      flag to the new field. Though the Delayed_insert::get_local_table
      copies the field->vcol_info for this field. Ad a result
      the parse_vcol_defs doesn't create the expression for that column
      so the field->vcol_info->expr is NULL. Which leads to crash.
      Backported fix for this from 10.5 - the flagg added in the
      Delayed_insert::get_local_table.
      
      Another problem with the USING HASH key is thst the
      parse_vcol_defs modifies the table->keys content. Then the same
      parse_vcol_defs is called on the table copy that has keys already
      modified. Backported fix for that from 10.5 - key copying added
      tot the Delayed_insert::get_local_table.
      
      Finally - the created copy has to clear the expr_arena as
      this table is not in the thd->open_tables list so won't be
      cleared automatically.
      8911823f
  11. 14 Jul, 2022 2 commits
  12. 13 Jul, 2022 1 commit
    • Igor Babaev's avatar
      MDEV-29088 Server crash upon CREATE VIEW with unknown column in ON condition · 65cc89ed
      Igor Babaev authored
      This bug caused crashes when the server executed such a CREATE VIEW
      statement whose view specification contained a reference to an unknown
      column in a subquery used in ON condition.
      The cause of this bug is quite similar to the cause of the bug MDEV-26412.
      The fix of this bug is quite similar to the fix for MDEV-26412.
      
      Approved by Sergey Petrunia <sergey@mariadb.com>
      65cc89ed