An error occurred fetching the project authors.
  1. 29 Jan, 2010 1 commit
    • Andrei Elkin's avatar
      Bug #50192 Strange effect in replication test, trigger, auto_increment · 7db8e764
      Andrei Elkin authored
      The auto-inc unsafe warning makes sense even though it's just
      one auto-inc table could be involved via a trigger or a stored
      function.
      However its content was not updated by bug@45677 fixes continuing to mention
      two tables whereas the fixes refined semantics of replication of auto_increment 
      in stored routine.
      
      Fixed with updating the error message, renaming the error and an internal unsafe-condition 
      constants.
      
      A documentation notice
      ======================
      
            Inserting into an autoincrement column in a stored function or a trigger
            is unsafe for replication.
            Even with just one autoincrement column, if the routine is invoked more than 
            once slave is not guaranteed to execute the statement graph same way as 
            the master.
            And since it's impossible to estimate how many times a routine can be invoked at 
            the query pre-execution phase (see lock_tables), the statement is marked
            pessimistically unsafe. 
      7db8e764
  2. 27 Nov, 2009 1 commit
  3. 03 Nov, 2009 1 commit
    • Alfranio Correia's avatar
      WL#2687 WL#5072 BUG#40278 BUG#47175 · 60d46624
      Alfranio Correia authored
      Non-transactional updates that take place inside a transaction present problems
      for logging because they are visible to other clients before the transaction
      is committed, and they are not rolled back even if the transaction is rolled
      back. It is not always possible to log correctly in statement format when both
      transactional and non-transactional tables are used in the same transaction.
      
      In the current patch, we ensure that such scenario is completely safe under the
      ROW and MIXED modes.
      60d46624
  4. 02 Nov, 2009 1 commit
    • Marc Alff's avatar
      Bug#9801 Views: imperfect error message · 1035de62
      Marc Alff authored
      Backport for 5.5
      
      The root cause of this bug is that the grammar for GROUP BY clauses,
      when using WITH CUBE or WITH ROLLUP, cause conflicts with the grammar
      for VIEW, when using WITH CHECK OPTION.
      
      The solution is to implement two token look ahead when parsing a WITH token,
      to disambiguate the non standard WITH CUBE and WITH ROLLUP syntaxes.
      
      Patch based on code from Marc Alff and Antony Curtis
      1035de62
  5. 21 Oct, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of revno 2630.28.10, 2630.28.31, 2630.28.26, 2630.33.1, · d4632dff
      Konstantin Osipov authored
      2630.39.1, 2630.28.29, 2630.34.3, 2630.34.2, 2630.34.1, 2630.29.29,
      2630.29.28, 2630.31.1, 2630.28.13, 2630.28.10, 2617.23.14 and
      some other minor revisions.
      
      This patch implements: 
      
      WL#4264 "Backup: Stabilize Service Interface" -- all the
      server prerequisites except si_objects.{h,cc} themselves (they can
      be just copied over, when needed).
      
      WL#4435: Support OUT-parameters in prepared statements.
      
      (and all issues in the initial patches for these two
      tasks, that were discovered in pushbuild and during testing).
      
      Bug#39519: mysql_stmt_close() should flush all data
      associated with the statement.
      
      After execution of a prepared statement, send OUT parameters of the invoked
      stored procedure, if any, to the client.
      
      When using the binary protocol, send the parameters in an additional result
      set over the wire.  When using the text protocol, assign out parameters to
      the user variables from the CALL(@var1, @var2, ...) specification.
      
      The following refactoring has been made:
        - Protocol::send_fields() was renamed to Protocol::send_result_set_metadata();
        - A new Protocol::send_result_set_row() was introduced to incapsulate
          common functionality for sending row data.
        - Signature of Protocol::prepare_for_send() was changed: this operation
          does not need a list of items, the number of items is fully sufficient.
      
      The following backward incompatible changes have been made:
        - CLIENT_MULTI_RESULTS is now enabled by default in the client;
        - CLIENT_PS_MULTI_RESUTLS is now enabled by default in the client.
      d4632dff
  6. 16 Oct, 2009 1 commit
  7. 14 Oct, 2009 3 commits
    • Konstantin Osipov's avatar
      Backport of: · 64dbe379
      Konstantin Osipov authored
      ----------------------------------------------------------
      revno: 2617.22.5
      committer: Konstantin Osipov <kostja@sun.com>
      branch nick: mysql-6.0-runtime
      timestamp: Tue 2009-01-27 05:08:48 +0300
      message:
        Remove non-prefixed use of HASH.
        Always use my_hash_init(), my_hash_inited(), my_hash_search(),
        my_hash_element(), my_hash_delete(), my_hash_free() rather
        than non-prefixed counterparts (hash_init(), etc).
        Remove the backward-compatible defines.
      64dbe379
    • Sven Sandberg's avatar
      BUG#39934: Slave stops for engine that only support row-based logging · 73b296c4
      Sven Sandberg authored
      Post-push fix.
      Problem: After the original bugfix, if a statement is unsafe,
      binlog_format=mixed, and engine is statement-only, a warning was
      generated and the statement executed. However, it is a fundamental
      principle of binlogging that binlog_format=mixed should guarantee
      correct logging, no compromise. So correct behavior is to generate
      an error and don't execute the statement.
      Fix: Generate error instead of warning.
      Since issue_unsafe_warnings can only generate one error message,
      this allows us to simplify the code a bit too:
      decide_logging_format does not have to save the error code for
      issue_unsafe_warnings
      73b296c4
    • Konstantin Osipov's avatar
      Backport of: · 4db335dc
      Konstantin Osipov authored
      ----------------------------------------------------------
      revno: 2630.22.8
      committer: Konstantin Osipov <konstantin@mysql.com>
      branch nick: mysql-6.0-runtime
      timestamp: Sun 2008-08-10 18:49:52 +0400
      message:
        Get rid of typedef struct for the most commonly used types:
        TABLE, TABLE_SHARE, LEX. This simplifies use of tags
        and forward declarations.
      4db335dc
  8. 09 Oct, 2009 1 commit
    • Dmitry Lenev's avatar
      This patch is prerequisite for the 2nd milestone of WL#148 "Foreign keys" · d4669dc4
      Dmitry Lenev authored
      storing and restoring information about foreign keys in the .FRM files and
      properly displaying it in SHOW CREATE TABLE output and I_S tables.
      
      The idea of this patch is to change type of Key_part_spec::field_name and
      Key::name to LEX_STRING in order to avoid extra strlen() calls during
      semantic analysis and statement execution, particularly, in code to be
      implemented on the 2nd milestone of WL#148.
      
      Note that since we are not using LEX_STRING everywhere yet (e.g. in
      Create_field and KEY) and we want to limit scope of our changes we
      have to do strlen() in places where we create Key and Key_part_spec
      instances from objects using plain (char*) for strings. These calls
      will go away during the process of further (char*) -> LEX_STRING
      refactoring.
      
      We have introduced these changes in 6.0 and backported them to 5.5
      tree to make people aware of these changes as early as possible and
      to simplify merges with mysql-fk and mysql-6.1-fk trees.
      
      No test case is needed since this patch does not introduce any
      user visible changes.
      d4669dc4
  9. 01 Oct, 2009 1 commit
  10. 17 Sep, 2009 1 commit
  11. 15 Sep, 2009 1 commit
  12. 08 Aug, 2009 1 commit
    • Davi Arnaut's avatar
      Bug#45010: invalid memory reads during parsing some strange statements · 69fbbdc1
      Davi Arnaut authored
      The problem is that the lexer could inadvertently skip over the
      end of a query being parsed if it encountered a malformed multibyte
      character. A specially crated query string could cause the lexer
      to jump up to six bytes past the end of the query buffer. Another
      problem was that the laxer could use unfiltered user input as
      a signed array index for the parser maps (having upper and lower
      bounds 0 and 256 respectively).
      
      The solution is to ensure that the lexer only skips over well-formed
      multibyte characters and that the index value of the parser maps
      is always a unsigned value.
      69fbbdc1
  13. 24 Jun, 2009 1 commit
    • MySQL Build Team's avatar
      Backport into build-200906240007-5.1.34sp1 · fab67c98
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2852.2.3
      > revision-id: davi.arnaut@sun.com-20090403194600-60ufn0tz1gx1kl0l
      > parent: gni@mysql.com-20090403184200-vnjtpsv4an79w8bu
      > parent: davi.arnaut@sun.com-20090403191154-0ho2nai3chjsmpof
      > committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      > branch nick: 43230-5.1
      > timestamp: Fri 2009-04-03 16:46:00 -0300
      > message:
      >   Merge Bug#43230 into mysql-5.1-bugteam
      >     ------------------------------------------------------------
      >     revno: 1810.3855.16
      >     revision-id: davi.arnaut@sun.com-20090403191154-0ho2nai3chjsmpof
      >     parent: chad@mysql.com-20090402152928-3ld60a56h86njcpg
      >     committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      >     branch nick: 43230-5.0
      >     timestamp: Fri 2009-04-03 16:11:54 -0300
      >     message:
      >       Bug#43230: SELECT ... FOR UPDATE can hang with FLUSH TABLES WITH READ LOCK indefinitely
      >       
      >       The problem is that a SELECT .. FOR UPDATE statement might open
      >       a table and later wait for a impeding global read lock without
      >       noticing whether it is holding a table that is being waited upon
      >       the the flush phase of the process that took the global read
      >       lock.
      >       
      >       The same problem also affected the following statements:
      >       
      >       LOCK TABLES .. WRITE
      >       UPDATE .. SET (update and multi-table update)
      >       TRUNCATE TABLE ..
      >       LOAD DATA ..
      >       
      >       The solution is to make the above statements wait for a impending
      >       global read lock before opening the tables. If there is no
      >       impending global read lock, the statement raises a temporary
      >       protection against global read locks and progresses smoothly
      >       towards completion.
      >       
      >       Important notice: the patch does not try to address all possible
      >       cases, only those which are common and can be fixed unintrusively
      >       enough for 5.0.
      fab67c98
  14. 17 Jun, 2009 1 commit
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · 30fccdaa
      Staale Smedseng authored
      with gcc 4.3.2
            
      Compiling MySQL with gcc 4.3.2 and later produces a number of 
      warnings, many of which are new with the recent compiler
      versions.
                        
      This bug will be resolved in more than one patch to limit the
      size of changesets. This is the second patch, fixing more
      of the warnings.
      30fccdaa
  15. 10 Jun, 2009 1 commit
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · e6e1f4ac
      Staale Smedseng authored
      with gcc 4.3.2
      
      Compiling MySQL with gcc 4.3.2 and later produces a number of 
      warnings, many of which are new with the recent compiler
      versions.
                  
      This bug will be resolved in more than one patch to limit the
      size of changesets. This is the second patch, fixing more
      of the warnings.
      e6e1f4ac
  16. 27 May, 2009 1 commit
  17. 10 Apr, 2009 1 commit
    • Chad MILLER's avatar
      Bug#39559: dump of stored procedures / functions with C-style \ · aa449c10
      Chad MILLER authored
      	comment can't be read back
      
      A change to the lexer in 5.1 caused slash-asterisk-bang-version
      sections to be terminated early if there exists a slash-asterisk-
      style comment inside it.  Nesting comments is usually illegal,
      but we rely on versioned comment blocks in mysqldump, and the
      contents of those sections must be allowed to have comments.
      
      The problem was that when encountering open-comment tokens and
      consuming -or- passing through the contents, the "in_comment"
      state at the end was clobbered with the not-in-a-comment value,
      regardless of whether we were in a comment before this or not.  
      
      So, """/*!VER one /* two */ three */""" would lose its in-comment
      state between "two" and "three".  Save the echo and in-comment
      state, and restore it at the end of the comment if we consume a 
      comment.
      aa449c10
  18. 03 Apr, 2009 1 commit
    • Davi Arnaut's avatar
      Bug#43230: SELECT ... FOR UPDATE can hang with FLUSH TABLES WITH READ LOCK indefinitely · aebaf079
      Davi Arnaut authored
      The problem is that a SELECT .. FOR UPDATE statement might open
      a table and later wait for a impeding global read lock without
      noticing whether it is holding a table that is being waited upon
      the the flush phase of the process that took the global read
      lock.
      
      The same problem also affected the following statements:
      
      LOCK TABLES .. WRITE
      UPDATE .. SET (update and multi-table update)
      TRUNCATE TABLE ..
      LOAD DATA ..
      
      The solution is to make the above statements wait for a impending
      global read lock before opening the tables. If there is no
      impending global read lock, the statement raises a temporary
      protection against global read locks and progresses smoothly
      towards completion.
      
      Important notice: the patch does not try to address all possible
      cases, only those which are common and can be fixed unintrusively
      enough for 5.0.
      aebaf079
  19. 05 Mar, 2009 1 commit
    • Kristofer Pettersson's avatar
      Bug#39843 DELETE requires write access to table in subquery in where clause · 16347772
      Kristofer Pettersson authored
      An unnecessarily restrictive lock were taken on sub-SELECTs during DELETE.
      
      During parsing, a global structure is reused for sub-SELECTs and the attribute
      keeping track of lock options were not reset properly.
      This patch introduces a new attribute to keep track on the syntactical lock
      option elements found in a sub-SELECT and then sets the lock options accordingly.
      
      Now the sub-SELECTs will try to acquire a READ lock if possible
      instead of a WRITE lock as inherited from the outer DELETE statement.
      16347772
  20. 10 Feb, 2009 1 commit
  21. 16 Dec, 2008 1 commit
  22. 10 Nov, 2008 1 commit
  23. 15 Oct, 2008 1 commit
    • Davi Arnaut's avatar
      Bug#37075: offset of limit clause might be truncated on 32-bits server w/o big tables · 4ab10baa
      Davi Arnaut authored
      The problem is that the offset argument of the limit clause
      might be truncated on a 32-bits server built without big
      tables support. The truncation was happening because the
      original 64-bits long argument was being cast to a 32-bits
      (ha_rows) offset counter.
      
      The solution is to check if the conversing resulted in value
      truncation and if so, the offset is set to the maximum possible
      value that can fit on the type.
      4ab10baa
  24. 07 Oct, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while · e219979e
      Gleb Shchepa authored
                ``FLUSH TABLES WITH READ LOCK''
      
      Concurrent execution of 1) multitable update with a
      NATURAL/USING join and 2) a such query as "FLUSH TABLES
      WITH READ LOCK" or "ALTER TABLE" of updating table led
      to a server crash.
      
      
      The mysql_multi_update_prepare() function call is optimized
      to lock updating tables only, so it postpones locking to
      the last, and if locking fails, it does cleanup of modified
      syntax structures and repeats a query analysis.  However,
      that cleanup procedure was incomplete for NATURAL/USING join
      syntax data: 1) some Field_item items pointed into freed
      table structures, and 2) the TABLE_LIST::join_columns fields
      was not reset.
      
      Major change:
        short-living Field *Natural_join_column::table_field has
        been replaced with long-living Item*.
      e219979e
  25. 18 Sep, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug#26020: User-Defined Variables are not consistent with · db1d38c9
      Gleb Shchepa authored
                 columns data types
      
      The "SELECT @lastId, @lastId := Id FROM t" query returns
      different result sets depending on the type of the Id column
      (INT or BIGINT).
      
      Note: this fix doesn't cover the case when a select query
      references an user variable and stored function that
      updates a value of that variable, in this case a result
      is indeterminate.
      
      
      The server uses incorrect assumption about a constantness of
      an user variable value as a select list item: 
      
      The server caches a last query number where that variable
      was changed and compares this number with a current query
      number. If these numbers are different, the server guesses,
      that the variable is not updating in the current query, so
      a respective select list item is a constant. However, in some
      common cases the server updates cached query number too late.
      
      
      The server has been modified to memorize user variable
      assignments during the parse phase to take them into account
      on the next (query preparation) phase independently of the
      order of user variable references/assignments in a select
      item list.
      db1d38c9
  26. 14 Jul, 2008 1 commit
    • Marc Alff's avatar
      Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on · 0816ee6d
      Marc Alff authored
      build)
      
      The crash was caused by freeing the internal parser stack during the parser
      execution.
      This occured only for complex stored procedures, after reallocating the parser
      stack using my_yyoverflow(), with the following C call stack:
      - MYSQLparse()
      - any rule calling sp_head::restore_lex()
      - lex_end()
      - x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs)
      
      The root cause is the implementation of stored procedures, which breaks the
      assumption from 4.1 that there is only one LEX structure per parser call.
      
      The solution is to separate the LEX structure into:
      - attributes that represent a statement (the current LEX structure),
      - attributes that relate to the syntax parser itself (Yacc_state),
      so that parsing multiple statements in stored programs can create multiple
      LEX structures while not changing the unique Yacc_state.
      
      Now, Yacc_state and the existing Lex_input_stream are aggregated into
      Parser_state, a structure that represent the complete state of the (Lexical +
      Syntax) parser.
      0816ee6d
  27. 07 Jul, 2008 1 commit
    • Marc Alff's avatar
      Bug#26030 (Parsing fails for stored routine w/multi-statement execution · f3ff1aeb
      Marc Alff authored
      enabled)
      
      Before this fix, the lexer and parser would treat the ';' character as a
      different token (either ';' or END_OF_INPUT), based on convoluted logic,
      which failed in simple cases where a stored procedure is implemented as a
      single statement, and used in a multi query.
      
      With this fix:
      - the character ';' is always parsed as a ';' token in the lexer,
      - parsing multi queries is implemented in the parser, in the 'query:' rules,
      - the value of thd->client_capabilities, which is the capabilities
        negotiated between the client and the server during bootstrap,
        is immutable and not arbitrarily modified during parsing (which was the
        root cause of the bug)
      f3ff1aeb
  28. 27 Mar, 2008 1 commit
    • evgen@moonbone.local's avatar
      Bug#27219: Aggregate functions in ORDER BY. · 21c6145a
      evgen@moonbone.local authored
      Mixing aggregate functions and non-grouping columns is not allowed in the
      ONLY_FULL_GROUP_BY mode. However in some cases the error wasn't thrown because
      of insufficient check.
      
      In order to check more thoroughly the new algorithm employs a list of outer
      fields used in a sum function and a SELECT_LEX::full_group_by_flag.
      Each non-outer field checked to find out whether it's aggregated or not and
      the current select is marked accordingly.
      All outer fields that are used under an aggregate function are added to the
      Item_sum::outer_fields list and later checked by the Item_sum::check_sum_func
      function.
      21c6145a
  29. 22 Feb, 2008 1 commit
    • anozdrin/alik@quad.'s avatar
      Fix for Bug#30217: Views: changes in metadata behaviour · 340906f4
      anozdrin/alik@quad. authored
      between 5.0 and 5.1.
        
      The problem was that in the patch for Bug#11986 it was decided
      to store original query in UTF8 encoding for the INFORMATION_SCHEMA.
      This approach however turned out to be quite difficult to implement
      properly. The main problem is to preserve the same IS-output after
      dump/restore.
        
      So, the fix is to rollback to the previous functionality, but also
      to fix it to support multi-character-set-queries properly. The idea
      is to generate INFORMATION_SCHEMA-query from the item-tree after
      parsing view declaration. The IS-query should:
        - be completely in UTF8;
        - not contain character set introducers.
        
      For more information, see WL4052.
      340906f4
  30. 05 Nov, 2007 1 commit
    • istruewing@stella.local's avatar
      Bug#31210 - INSERT DELAYED crashes server when used on · 3eaf82a1
      istruewing@stella.local authored
                  partitioned table
      
      Trying INSERT DELAYED on a partitioned table, that has not been
      used right before, crashes the server. When a table is used for
      select or update, it is kept open for some time. This period I
      mean with "right before".
      
      Information about partitioning of a table is stored in form of
      a string in the .frm file. Parsing of this string requires a
      correctly set up lexical analyzer (lex). The partitioning code
      uses a new temporary instance of a lex. But it does still refer
      to the previously active lex. The delayd insert thread does not
      initialize its lex though...
      
      Added initialization for thd->lex before open table in the delayed
      thread and at all other places where it is necessary to call
      lex_start() if all tables would be partitioned and need to parse
      the .frm file.
      3eaf82a1
  31. 09 Oct, 2007 1 commit
  32. 19 Sep, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #30639: limit offset,rowcount wraps when rowcount >= 2^32 in windows · c2abf960
      gkodinov/kgeorge@magare.gmz authored
       The parser uses ulonglong to store the LIMIT number. This number
       then is stored into a variable of type ha_rows. ha_rows is either
       4 or 8 byte depending on the BIG_TABLES define from config.h
       So an overflow may occur (and LIMIT becomes zero) while storing an
       ulonglong value in ha_rows.
       Fixed by :
        1. Using the maximum possible value for ha_rows on overflow
        2. Defining BIG_TABLES for the windows builds (to match the others) 
      c2abf960
  33. 30 Aug, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#28779 (mysql_query() allows execution of statements with unbalanced · 4792ed42
      malff/marcsql@weblab.(none) authored
      comments)
      
      This change set is for 5.1 (manually merged)
      
      Before this fix, the server would accept queries that contained comments,
      even when the comments were not properly closed with a '*' '/' marker.
      
      For example,
        select 1 /* + 2 <EOF>
      would be accepted as
        select 1 /* + 2 */ <EOF>
      and executed as
        select 1
      
      With this fix, the server now rejects queries with unclosed comments
      as syntax errors.
      Both regular comments ('/' '*') and special comments ('/' '*' '!') must be
      closed with '*' '/' to be parsed correctly.
      4792ed42
  34. 29 Aug, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#28779 (mysql_query() allows execution of statements with unbalanced · 6f72d990
      malff/marcsql@weblab.(none) authored
      comments)
      
      Before this fix, the server would accept queries that contained comments,
      even when the comments were not properly closed with a '*' '/' marker.
      
      For example,
        select 1 /* + 2 <EOF>
      would be accepted as
        select 1 /* + 2 */ <EOF>
      and executed as
        select 1
      
      With this fix, the server now rejects queries with unclosed comments
      as syntax errors.
      Both regular comments ('/' '*') and special comments ('/' '*' '!') must be
      closed with '*' '/' to be parsed correctly.
      6f72d990
  35. 23 Aug, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #30396. · 4a7fdf86
      gshchepa/uchum@gleb.loc authored
      Recommit to 5.1.22.
      The bug caused memory corruption for some queries with top OR level
      in the WHERE condition if they contained equality predicates and 
      other sargable predicates in disjunctive parts of the condition.
      
      The corruption happened because the upper bound of the memory
      allocated for KEY_FIELD and SARGABLE_PARAM internal structures
      containing info about potential lookup keys was calculated incorrectly
      in some cases. In particular it was calculated incorrectly when the
      WHERE condition was an OR formula with disjuncts being AND formulas
      including equalities and other sargable predicates.
      4a7fdf86
  36. 22 Aug, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#30333 (Performance, expressions lists in the parser) · 81114a72
      malff/marcsql@weblab.(none) authored
      Before this patch, the parser would execute:
      - Select->expr_list.push_front()
      - Select->expr_list.pop()
      when parsing expressions lists, in the following rules:
      - udf_expr_list
      - expr_list
      - ident_list
      
      This is unnecessary, and introduces overhead due to the memory allocations
      performed with Select->expr_list
      
      With this patch, this code has been removed.
      The list being parsed is maintained in the parser stack instead.
      
      Also, 'udf_expr_list' has been renamed 'opt_udf_expr_list', since this
      production can be empty.
      81114a72
  37. 16 Aug, 2007 1 commit
  38. 15 Aug, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #30396. · d790ec42
      igor@olga.mysql.com authored
      The bug caused memory corruption for some queries with top OR level
      in the WHERE condition if they contained equality predicates and 
      other sargable predicates in disjunctive parts of the condition.
      
      The corruption happened because the upper bound of the memory
      allocated for KEY_FIELD and SARGABLE_PARAM internal structures
      containing info about potential lookup keys was calculated incorrectly
      in some cases. In particular it was calculated incorrectly when the
      WHERE condition was an OR formula with disjuncts being AND formulas
      including equalities and other sargable predicates.
      d790ec42