An error occurred fetching the project authors.
  1. 11 Sep, 2021 1 commit
  2. 16 Jul, 2021 1 commit
    • Nikita Malyavin's avatar
      MDEV-23597 Assertion `marked_for_read()' failed while evaluating DEFAULT · c47e4aab
      Nikita Malyavin authored
      The columns that are part of DEFAULT expression were not read-marked
      in statements like UPDATE...SET b=DEFAULT.
      
      The problem is `F(DEFAULT)` expression depends of the left-hand side of an
      assignment. However, setup_fields accepts only right-hand side value.
      Neither Item::fix_fields does.
      
      Suchwise, b=DEFAULT(b) works fine, because Item_default_field has
      information on what field it is default of:
          if (thd->mark_used_columns != MARK_COLUMNS_NONE)
            def_field->default_value->expr->update_used_tables();
      
      in Item_default_value::fix_fields().
      
      It is not reasonable to pass a left-hand side to Item:fix_fields, because
      the case is rare, so the rewrite
        b= F(DEFAULT)  ->  b= F(DEFAULT(b))
      
      is made instead.
      
      Both UPDATE and multi-UPDATE are affected, however any form of INSERT
      is not: it marks all the fields in DEFAULT expressions for read in
      TABLE::mark_default_fields_for_write().
      c47e4aab
  3. 21 May, 2021 1 commit
    • Igor Babaev's avatar
      MDEV-23886 Reusing CTE inside a function fails with table doesn't exist · 43c9fcef
      Igor Babaev authored
      In the code existed just before this patch binding of a table reference to
      the specification of the corresponding CTE happens in the function
      open_and_process_table(). If the table reference is not the first in the
      query the specification is cloned in the same way as the specification of
      a view is cloned for any reference of the view. This works fine for
      standalone queries, but does not work for stored procedures / functions
      for the following reason.
      When the first call of a stored procedure/ function SP is processed the
      body of SP is parsed. When a query of SP is parsed the info on each
      encountered table reference is put into a TABLE_LIST object linked into
      a global chain associated with the query. When parsing of the query is
      finished the basic info on the table references from this chain except
      table references to derived tables and information schema tables is put
      in one hash table associated with SP. When parsing of the body of SP is
      finished this hash table is used to construct TABLE_LIST objects for all
      table references mentioned in SP and link them into the list of such
      objects passed to a pre-locking process that calls open_and_process_table()
      for each table from the list.
      When a TABLE_LIST for a view is encountered the view is opened and its
      specification is parsed. For any table reference occurred in
      the specification a new TABLE_LIST object is created to be included into
      the list for pre-locking. After all objects in the pre-locking have been
      looked through the tables mentioned in the list are locked. Note that the
      objects referenced CTEs are just skipped here as it is impossible to
      resolve these references without any info on the context where they occur.
      Now the statements from the body of SP are executed one by one that.
      At the very beginning of the execution of a query the tables used in the
      query are opened and open_and_process_table() now is called for each table
      reference mentioned in the list of TABLE_LIST objects associated with the
      query that was built when the query was parsed.
      For each table reference first the reference is checked against CTEs
      definitions in whose scope it occurred. If such definition is found the
      reference is considered resolved and if this is not the first reference
      to the found CTE the the specification of the CTE is re-parsed and the
      result of the parsing is added to the parsing tree of the query as a
      sub-tree. If this sub-tree contains table references to other tables they
      are added to the list of TABLE_LIST objects associated with the query in
      order the referenced tables to be opened. When the procedure that opens
      the tables comes to the TABLE_LIST object created for a non-first
      reference to a CTE it discovers that the referenced table instance is not
      locked and reports an error.
      Thus processing non-first table references to a CTE similar to how
      references to view are processed does not work for queries used in stored
      procedures / functions. And the main problem is that the current
      pre-locking mechanism employed for stored procedures / functions does not
      allow to save the context in which a CTE reference occur. It's not trivial
      to save the info about the context where a CTE reference occurs while the
      resolution of the table reference cannot be done without this context and
      consequentially the specification for the table reference cannot be
      determined.
      
      This patch solves the above problem by moving resolution of all CTE
      references at the parsing stage. More exactly references to CTEs occurred in
      a query are resolved right after parsing of the query has finished. After
      resolution any CTE reference it is marked as a reference to to derived
      table. So it is excluded from the hash table created for pre-locking used
      base tables and view when the first call of a stored procedure / function
      is processed.
      This solution required recursive calls of the parser. The function
      THD::sql_parser() has been added specifically for recursive invocations of
      the parser.
      43c9fcef
  4. 28 Apr, 2021 1 commit
    • Oleksandr Byelkin's avatar
      Bug#29363867: LOST CONNECTION TO MYSQL SERVER DURING QUERY · 24693c6f
      Oleksandr Byelkin authored
      The problem is that sharing default expression among set instruction
      leads to attempt access result field of function created in
      other instruction runtime MEM_ROOT and already freed
      (a bit different then MySQL problem).
      
      Fix is the same as in MySQL (but no optimisation for constant), turn
      DECLARE a, b, c type DEFAULT expr;
      to
      DECLARE a type DEFAULT expr, b type DEFAULT a, c type DEFAULT a;
      24693c6f
  5. 24 Jan, 2021 1 commit
  6. 11 Jan, 2021 1 commit
    • Sergei Golubchik's avatar
      MDEV-12161 Can't specify collation for virtual columns · 4c448836
      Sergei Golubchik authored
      sql standard (2016) allows <collate clause> in two places in the
      <column definition> - as a part of the <data type> or at the very end.
      
      Let's do that too.
      
      Side effect: in column/SP declaration `COLLATE cs_coll` automatically
      implies `CHARACTER SET cs` (unless charset was specified explicitly).
      See changes in sp-ucs2.result
      4c448836
  7. 10 Dec, 2020 1 commit
  8. 23 Oct, 2020 1 commit
    • Sergei Golubchik's avatar
      precedence bugfixing · 05a878c1
      Sergei Golubchik authored
      fix printing precedence for BETWEEN, LIKE/ESCAPE, REGEXP, IN
      don't use precedence for printing CASE/WHEN/THEN/ELSE/END
      
      fix parsing precedence of BETWEEN, LIKE/ESCAPE, REGEXP, IN
      support predicate arguments for IN, BETWEEN, SOUNDS LIKE, LIKE/ESCAPE,
      REGEXP
      
      use %nonassoc for unary operators
      
      fix parsing of IS TRUE/FALSE/UNKNOWN/NULL
      
      remove parser_precedence test as superseded by the precedence test
      05a878c1
  9. 06 Oct, 2020 1 commit
  10. 24 Sep, 2020 1 commit
  11. 20 Sep, 2020 5 commits
  12. 10 Feb, 2020 1 commit
  13. 14 Jan, 2020 1 commit
    • Sergei Petrunia's avatar
      MDEV-21341: Fix UBSAN failures: Issue Six · 5e5ae51b
      Sergei Petrunia authored
      (Variant #2 of the patch, which keeps the sp_head object inside the
      MEM_ROOT that sp_head object owns)
      (10.3 requires extra work due to sp_package, will commit a separate
      patch for it)
      
      sp_head::operator new() and operator delete() were dereferencing sp_head*
      pointers to memory that didn't hold a valid sp_head object (it was
      not created/already destroyed).
      This caused UBSan to crash when looking up type information.
      
      Fixed by providing static sp_head::create() and sp_head::destroy() methods.
      5e5ae51b
  14. 20 Sep, 2019 1 commit
  15. 11 Sep, 2019 1 commit
  16. 11 Jul, 2019 1 commit
    • Igor Babaev's avatar
      MDEV-19421 Basic 3-way join queries are not parsed. · 8540fa83
      Igor Babaev authored
      The parser returned a syntax error message for the queries with join
      expressions like this t1 JOIN t2 [LEFT | RIGHT] JOIN t3 ON ... ON ... when
      the second operand of the outer JOIN operation with ON clause was another
      join expression with ON clause. In this expression the JOIN operator is
      right-associative, i.e. expression has to be parsed as the expression
      t1 JOIN (t2 [LEFT | RIGHT] JOIN t3 ON ... ) ON ...
      Such join expressions are hard to parse because the outer JOIN is
      left-associative if there is no ON clause for the first outer JOIN operator.
      The patch implements the solution when the JOIN operator is always parsed
      as right-associative and builds first the right-associative tree. If it
      happens that there is no corresponding ON clause for this operator the
      tree is converted to left-associative.
      
      The idea of the solution was taken from the patch by Martin Hansson
      "WL#8083: Fixed the join_table rule" from MySQL-8.0 code line.
      As the grammar rules related to join expressions in MySQL-8.0 and
      MariaDB-5.5+ are quite different MariaDB solution could not borrow
      any code from the MySQL-8.0 solution.
      8540fa83
  17. 31 May, 2019 1 commit
  18. 11 May, 2019 1 commit
  19. 24 Apr, 2019 3 commits
    • Sergei Golubchik's avatar
      MDEV-18507 can't update temporary table when joined with table with triggers on read-only · 5d510fdb
      Sergei Golubchik authored
      triggers are opened and tables used in triggers are prelocked in
      open_tables(). But multi-update can detect what tables will actually
      be updated only later, after all main tables are opened.
      
      Meaning, if a table is used in multi-update, but is not actually updated,
      its on-update treggers will be opened and tables will be prelocked,
      even if it's unnecessary. This can cause more tables to be
      write-locked than needed, causing read_only errors, privilege errors
      and lock waits.
      
      Fix: don't open/prelock triggers unless table->updating is true.
      In multi-update after setting table->updating=true, do a second
      open_tables() for newly added tables, if any.
      5d510fdb
    • Sergei Golubchik's avatar
      bugfix: multi-update checked privileges on views incorrectly · 5057d463
      Sergei Golubchik authored
      it always required UPDATE privilege on views, not being able to detect
      when a views was not actually updated in multi-update.
      
      fix: instead of marking all tables as "updating" by default,
      only set "updating" on tables that will actually be updated
      by multi-update. And mark the view "updating" if any of the
      view's tables is.
      5057d463
    • Sergei Golubchik's avatar
      cleanup · 66099b8f
      Sergei Golubchik authored
      66099b8f
  20. 14 Mar, 2019 1 commit
    • Sergei Golubchik's avatar
      fix gcc 8 compiler warnings · 3d2d060b
      Sergei Golubchik authored
      There were two newly enabled warnings:
      1. cast for a function pointers. Affected sql_analyse.h, mi_write.c
         and ma_write.cc, mf_iocache-t.cc, mysqlbinlog.cc, encryption.cc, etc
      
      2. memcpy/memset of nontrivial structures. Fixed as:
      * the warning disabled for InnoDB
      * TABLE, TABLE_SHARE, and TABLE_LIST got a new method reset() which
        does the bzero(), which is safe for these classes, but any other
        bzero() will still cause a warning
      * Table_scope_and_contents_source_st uses `TABLE_LIST *` (trivial)
        instead of `SQL_I_List<TABLE_LIST>` (not trivial) so it's safe to
        bzero now.
      * added casts in debug_sync.cc and sql_select.cc (for JOIN)
      * move assignment method for MDL_request instead of memcpy()
      * PARTIAL_INDEX_INTERSECT_INFO::init() instead of bzero()
      * remove constructor from READ_RECORD() to make it trivial
      * replace some memcpy() with c++ copy assignments
      3d2d060b
  21. 12 Mar, 2019 1 commit
    • Sergei Golubchik's avatar
      MDEV-15945 --ps-protocol does not test some queries · a62e9a83
      Sergei Golubchik authored
      Make mysqltest to use --ps-protocol more
      
      use prepared statements for everything that server supports
      with the exception of CALL (for now).
      
      Fix discovered test failures and bugs.
      
      tests:
      * PROCESSLIST shows Execute state, not Query
      * SHOW STATUS increments status variables more than in text protocol
      * multi-statements should be avoided (see tests with a wrong delimiter)
      * performance_schema events have different names in --ps-protocol
      * --enable_prepare_warnings
      
      mysqltest.cc:
      * make sure run_query_stmt() doesn't crash if there's
        no active connection (in wait_until_connected_again.inc)
      * prepare all statements that server supports
      
      protocol.h
      * Protocol_discard::send_result_set_metadata() should not send
        anything to the client.
      
      sql_acl.cc:
      * extract the functionality of getting the user for SHOW GRANTS
        from check_show_access(), so that mysql_test_show_grants() could
        generate the correct column names in the prepare step
      
      sql_class.cc:
      * result->prepare() can fail, don't ignore its return value
      * use correct number of decimals for EXPLAIN columns
      
      sql_parse.cc:
      * discard profiling for SHOW PROFILE. In text protocol it's done in
        prepare_schema_table(), but in --ps it is called on prepare only,
        so nothing was discarding profiling during execute.
      * move the permission checking code for SHOW CREATE VIEW to
        mysqld_show_create_get_fields(), so that it would be called during
        prepare step too.
      * only set sel_result when it was created here and needs to be
        destroyed in the same block. Avoid destroying lex->result.
      * use the correct number of tables in check_show_access(). Saying
        "as many as possible" doesn't work when first_not_own_table isn't
        set yet.
      
      sql_prepare.cc:
      * use correct user name for SHOW GRANTS columns
      * don't ignore verbose flag for SHOW SLAVE STATUS
      * support preparing REVOKE ALL and ROLLBACK TO SAVEPOINT
      * don't ignore errors from thd->prepare_explain_fields()
      * use select_send result for sending ANALYZE and EXPLAIN, but don't
        overwrite lex->result, because it might be needed to issue execute-time
        errors (select_dumpvar - too many rows)
      
      sql_show.cc:
      * check grants for SHOW CREATE VIEW here, not in mysql_execute_command
      
      sql_view.cc:
      * use the correct function to check privileges. Old code was doing
        check_access() for thd->security_ctx, which is invoker's sctx,
        not definer's sctx. Hide various view related errors from the invoker.
      
      sql_yacc.yy:
      * initialize lex->select_lex for LOAD, otherwise it'll contain garbage
        data that happen to fail tests with views in --ps (but not otherwise).
      a62e9a83
  22. 06 Feb, 2019 1 commit
  23. 05 Feb, 2019 1 commit
  24. 24 Jan, 2019 1 commit
    • Andrei Elkin's avatar
      MDEV-10963 Fragmented BINLOG query · 5d48ea7d
      Andrei Elkin authored
      The problem was originally stated in
        http://bugs.mysql.com/bug.php?id=82212
      The size of an base64-encoded Rows_log_event exceeds its
      vanilla byte representation in 4/3 times.
      When a binlogged event size is about 1GB mysqlbinlog generates
      a BINLOG query that can't be send out due to its size.
      
      It is fixed with fragmenting the BINLOG argument C-string into
      (approximate) halves when the base64 encoded event is over 1GB size.
      The mysqlbinlog in such case puts out
      
          SET @binlog_fragment_0='base64-encoded-fragment_0';
          SET @binlog_fragment_1='base64-encoded-fragment_1';
          BINLOG @binlog_fragment_0, @binlog_fragment_1;
      
      to represent a big BINLOG.
      For prompt memory release BINLOG handler is made to reset the BINLOG argument
      user variables in the middle of processing, as if @binlog_fragment_{0,1} = NULL
      is assigned.
      
      Notice the 2 fragments are enough, though the client and server still may
      need to tweak their @@max_allowed_packet to satisfy to the fragment
      size (which they would have to do anyway with greater number of
      fragments, should that be desired).
      
      On the lower level the following changes are made:
      
      Log_event::print_base64()
        remains to call encoder and store the encoded data into a cache but
        now *without* doing any formatting. The latter is left for time
        when the cache is copied to an output file (e.g mysqlbinlog output).
        No formatting behavior is also reflected by the change in the meaning
        of the last argument which specifies whether to cache the encoded data.
      
      Rows_log_event::print_helper()
        is made to invoke a specialized fragmented cache-to-file copying function
        which is
      
      copy_cache_to_file_wrapped()
        that takes care of fragmenting also optionally wraps encoded
        strings (fragments) into SQL stanzas.
      
      my_b_copy_to_file()
        is refactored to into my_b_copy_all_to_file(). The former function
        is generalized
        to accepts more a limit argument to constraint the copying and does
        not reinitialize anymore the cache into reading mode.
        The limit does not do any effect on the fully read cache.
      5d48ea7d
  25. 23 Jan, 2019 1 commit
    • Sreeharsha Ramanavarapu's avatar
      Bug #28499924: INCORRECT BEHAVIOR WITH UNION IN SUBQUERY · b20d94da
      Sreeharsha Ramanavarapu authored
      Issue:
      ------
      When a subquery contains UNION the count of the number of
      subquery columns is calculated incorrectly. Only the first
      query block in the subquery's UNION is considered and an
      array indexing goes out-of-bounds, and this is caught by an
      assert.
      
      Solution:
      ---------
      Sum up the columns from all query blocks of the query
      expression.
      
      Change specific to 5.6/5.5:
      ---------------------------
      The "child" points to the last query block of the UNION
      (as opposed to 5.7+ where it points to the first member of
      UNION). So "child->master_unit()->first_select()" is used
      to reach the first query block of UNION.
      b20d94da
  26. 01 Nov, 2018 1 commit
  27. 16 Oct, 2018 1 commit
    • Andrei Elkin's avatar
      MDEV-14431 binlog.binlog_flush_binlogs_delete_domain failed in buildbot · d8974ebd
      Andrei Elkin authored
      The test and also rpl_gtid_delete_domain failed on PPC64 platform
      due to an incorrectly specified actual key for searching
      in a gtid domain system hash. While the correct size is 32 bits
      the supplied value was 8 bytes of long int size on the platform.
      The problem became evident thanks to the big endiness which
      cut off the *least* significant part of the value field.
      
      Fixed with correcting a dynamic array initialization to hold
      now uint32 values as well as the values extraction for
      searching in the gtid domain system hash.
      A new added test ensures no overflowed values are accepted
      for deletion which prevents inadvertent action. Notice though
      
      MariaDB [test]> set @@session.gtid_domain_id=(1 << 32) + 1;
      MariaDB [test]> show warnings;
      +---------+------+--------------------------------------------------------+
      | Level   | Code | Message                                                |
      +---------+------+--------------------------------------------------------+
      | Warning | 1292 | Truncated incorrect gtid_domain_id value: '4294967297' |
      +---------+------+--------------------------------------------------------+
      MariaDB [test]> select @@session.gtid_domain_id;
      +--------------------------+
      | @@session.gtid_domain_id |
      +--------------------------+
      |               4294967295 |
      +--------------------------+
      d8974ebd
  28. 15 Sep, 2018 2 commits
    • Igor Babaev's avatar
      Fixed a compiler warning. · 7419f72b
      Igor Babaev authored
      7419f72b
    • Igor Babaev's avatar
      MDEV-17154 Multiple selects from parametrized CTE fails with syntax error · 3473e045
      Igor Babaev authored
      This patch fills a serious flaw in the implementation of common table
      expressions. Before this patch an attempt to prepare a statement from
      a query with a parameter marker in a CTE that was used more than once
      in the query ended up with a bogus error message. Similarly if a statement
      in a stored procedure contained a CTE whose specification used a
      local variables and this CTE was referred to more than once in the
      statement then the server failed to execute the stored procedure returning
      a bogus error message on a non-existing field.
      
      The problems appeared due to incorrect handling of parameter markers /
      local variables in CTEs that were referred more than once.
      
      This patch fixes the problems by differentiating between the original
      occurrences of a parameter marker / local variable used in the
      specification of a CTE and the corresponding occurrences used
      in copies of this specification. These copies are substituted
      instead of non-first references to the CTE.
      
      The idea of the fix and even some code were taken from the MySQL
      implementation of the common table expressions.
      3473e045
  29. 04 Sep, 2018 2 commits
  30. 19 Aug, 2018 1 commit
    • Sreeharsha Ramanavarapu's avatar
      Bug #26791931: INCORRECT BEHAVIOR IN ALTER TABLE REORGANIZE · a653fca9
      Sreeharsha Ramanavarapu authored
                     PARTITION
      
      Issue:
      ------
      ALTER TABLE REORGANIZE PARTITION .... can result in
      incorrect behavior if any partition other than the last
      one misses the "VALUES LESS THAN..." part of the syntax.
      
      Root cause:
      -----------
      Currently ALTER TABLE with changes to partitions is handled
      incorrectly by the parser.
      
      Fix:
      ----
      The if condition which handles partition management
      differently for ALTER TABLE in the parser should be removed.
       Change the code to handle the case in the parser.
      a653fca9
  31. 18 May, 2018 1 commit
  32. 27 Mar, 2018 1 commit