1. 17 Dec, 2010 2 commits
  2. 16 Dec, 2010 2 commits
    • Martin Hansson's avatar
      Merge. · 7d2b182d
      Martin Hansson authored
      7d2b182d
    • Martin Hansson's avatar
      Bug#54568: create view cause Assertion failed: 0, · ff15ebdd
      Martin Hansson authored
      file .\item_subselect.cc, line 836
           
      IN quantified predicates are never executed directly. They are rather wrapped
      inside nodes called IN Optimizers (Item_in_optimizer) which take care of the
      execution. However, this is not done during query preparation. Unfortunately
      the LIKE predicate pre-evaluates constant right-hand side arguments even
      during name resolution. Likely this is meant as an optimization.
            
      Fixed by not pre-evaluating LIKE arguments in view prepare mode.
      
      Back-ported to 5.0s
      ff15ebdd
  3. 15 Dec, 2010 1 commit
    • Alexander Nozdrin's avatar
      Patch for Bug#57952 (privilege change is not taken into account by EXECUTE). · 39036ca6
      Alexander Nozdrin authored
      The user-visible problem was that changes to column-level privileges,
      happened in between of PREPARE and EXECUTE of a prepared statement, were
      neglected. I.e. a prepared statement could be executed with the
      column-level privileges as of PREPARE-time. The problem existed for
      column-level privileges only.
      
      A similar problem existed for stored programs: the changes between
      executions didn't have an effect.
      
      Technically the thing is that table references are cached in
      Prepared_statement::prepare() call. In subsequent
      Prepared_statement::execute() calls those cached values are used.
      There are two functions to get a field by name: find_field_in_table() and
      find_field_in_table_ref(). On prepare-phase find_field_in_table_ref() is
      called, on execute-phase -- find_field_in_table() because the table is
      cached. find_field_in_table() does not check column-level privileges and
      expects the caller to do that. The problem was that this check was
      forgotten.
      
      The fix is to check them there as it happens in find_field_in_table_ref().
      39036ca6
  4. 14 Dec, 2010 1 commit
    • Gleb Shchepa's avatar
      backport of bug #54476 fix from 5.1-bugteam to 5.0-bugteam. · 01521a0a
      Gleb Shchepa authored
      Original revid: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l
      
       > Bug #54476: crash when group_concat and 'with rollup' in
       >                      prepared statements
       >
       > Using GROUP_CONCAT() together with the WITH ROLLUP modifier
       > could crash the server.
       >
       > The reason was a combination of several facts:
       >
       > 1. The Item_func_group_concat class stores pointers to ORDER
       > objects representing the columns in the ORDER BY clause of
       > GROUP_CONCAT().
       >
       > 2. find_order_in_list() called from
       > Item_func_group_concat::setup() modifies the ORDER objects so
       > that their 'item' member points to the arguments list
       > allocated in the Item_func_group_concat constructor.
       >
       > 3. In some cases (e.g. in JOIN::rollup_make_fields) a copy of
       > the original Item_func_group_concat object could be created by
       > using the Item_func_group_concat::Item_func_group_concat(THD
       > *thd, Item_func_group_concat *item) copy constructor. The
       > latter essentially creates a shallow copy of the source
       > object. Memory for the arguments array is allocated on
       > thd->mem_root, but the pointers for arguments and ORDER are
       > copied verbatim.
       >
       > What happens in the test case is that when executing the query
       > for the first time, after a copy of the original
       > Item_func_group_concat object has been created by
       > JOIN::rollup_make_fields(), find_order_in_list() is called for
       > this new object. It then resolves ORDER BY by modifying the
       > ORDER objects so that they point to elements of the arguments
       > array which is local to the cloned object. When thd->mem_root
       > is freed upon completing the execution, pointers in the ORDER
       > objects become invalid. Those ORDER objects, however, are also
       > shared with the original Item_func_group_concat object which is
       > preserved between executions of a prepared statement. So the
       > first call to find_order_in_list() for the original object on
       > the second execution tries to dereference an invalid pointer.
       >
       > The solution is to create copies of the ORDER objects when
       > copying Item_func_group_concat to not leave any stale pointers
       > in other instances with different lifecycles.
      01521a0a
  5. 08 Dec, 2010 1 commit
  6. 03 Dec, 2010 1 commit
  7. 30 Nov, 2010 2 commits
  8. 29 Nov, 2010 2 commits
  9. 24 Nov, 2010 4 commits
    • Gleb Shchepa's avatar
      backport of bug #54461 from 5.1-security to 5.0-security · d85c3053
      Gleb Shchepa authored
       > revision-id: gshchepa@mysql.com-20100801181236-uyuq6ewaq43rw780
       > parent: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l
       > committer: Gleb Shchepa <gshchepa@mysql.com>
       > branch nick: mysql-5.1-security
       > timestamp: Sun 2010-08-01 22:12:36 +0400
       > Bug #54461: crash with longblob and union or update with subquery
       >
       > Queries may crash, if
       >   1) the GREATEST or the LEAST function has a mixed list of
       >      numeric and LONGBLOB arguments and
       >   2) the result of such a function goes through an intermediate
       >      temporary table.
       >
       > An Item that references a LONGBLOB field has max_length of
       > UINT_MAX32 == (2^32 - 1).
       >
       > The current implementation of GREATEST/LEAST returns REAL
       > result for a mixed list of numeric and string arguments (that
       > contradicts with the current documentation, this contradiction
       > was discussed and it was decided to update the documentation).
       >
       > The max_length of such a function call was calculated as a
       > maximum of argument max_length values (i.e. UINT_MAX32).
       >
       > That max_length value of UINT_MAX32 was used as a length for
       > the intermediate temporary table Field_double to hold
       > GREATEST/LEAST function result.
       >
       > The Field_double::val_str() method call on that field
       > allocates a String value.
       >
       > Since an allocation of String reserves an additional byte
       > for a zero-termination, the size of String buffer was
       > set to (UINT_MAX32 + 1), that caused an integer overflow:
       > actually, an empty buffer of size 0 was allocated.
       >
       > An initialization of the "first" byte of that zero-size
       > buffer with '\0' caused a crash.
       >
       > The Item_func_min_max::fix_length_and_dec() has been
       > modified to calculate max_length for the REAL result like
       > we do it for arithmetical operators.
      d85c3053
    • Alexander Nozdrin's avatar
      A follow-up for Bug#58339 (Replace Server GPL README file). · b6b7fb2b
      Alexander Nozdrin authored
      Fix formatting issues in README file.
      b6b7fb2b
    • Alexander Nozdrin's avatar
      Merge from mysql-5.0-bugteam. · 47cfb2c5
      Alexander Nozdrin authored
      47cfb2c5
    • Alexander Nozdrin's avatar
      A follow-up for Bug#58340 (Remove Server GPL EXCEPTIONS-CLIENT file) -- remove all · 174a6962
      Alexander Nozdrin authored
      EXCEPTIONS-CLIENT from all the places.
      174a6962
  10. 23 Nov, 2010 1 commit
  11. 22 Nov, 2010 3 commits
    • Gleb Shchepa's avatar
      backport: Bug #55568 from 5.1-security to 5.0-security · 3586f772
      Gleb Shchepa authored
      > revision-id: alexey.kopytov@sun.com-20100824103548-ikm79qlfrvggyj9h
      > parent: sunny.bains@oracle.com-20100816001222-xqc447tr6jwh8c53
      > committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
      > branch nick: 5.1-security
      > timestamp: Tue 2010-08-24 14:35:48 +0400
      > message:
      >   Bug #55568: user variable assignments crash server when used
      >               within query
      >   
      >   The server could crash after materializing a derived table
      >   which requires a temporary table for grouping.
      >   
      >   When destroying the temporary table used to execute a query for
      >   a derived table, JOIN::destroy() did not clean up Item_fields
      >   pointing to fields in the temporary table. This led to
      >   dereferencing a dangling pointer when printing out the items
      >   tree later in the outer SELECT.
      >   
      >   The solution is an addendum to the patch for bug37362: in
      >   addition to cleaning up items in tmp_all_fields3, do the same
      >   for items in tmp_all_fields1, since now we have an example
      >   where this is necessary.
      3586f772
    • Alexander Nozdrin's avatar
    • Alexander Nozdrin's avatar
  12. 08 Nov, 2010 2 commits
  13. 29 Oct, 2010 1 commit
  14. 05 Oct, 2010 4 commits
  15. 20 Aug, 2010 2 commits
  16. 10 Aug, 2010 1 commit
  17. 02 Aug, 2010 2 commits
  18. 30 Jul, 2010 1 commit
  19. 21 Jul, 2010 2 commits
  20. 15 Jul, 2010 1 commit
    • Alexey Kopytov's avatar
      Backport of the fix for bug#25421 to 5.0. · a42108c2
      Alexey Kopytov authored
      Calculating the estimated number of records for a range scan
      may take a significant time, and it was impossible for a user
      to interrupt that process by killing the connection or the
      query.
      
      Fixed by checking the thread's 'killed' status in
      check_quick_keys() and interrupting the calculation process if
      it is set to a non-zero value.
      a42108c2
  21. 07 Jul, 2010 1 commit
    • Vasil Dimov's avatar
      Merge the fix for Bug#49238 from SVN · 7c6ba7b4
      Vasil Dimov authored
      (without the unrelated whitespace changes):
      
        ------------------------------------------------------------------------
        r7009 | jyang | 2010-04-29 20:44:56 +0300 (Thu, 29 Apr 2010) | 6 lines
        
        branches/5.0: Port fix for bug #49238 (Creating/Dropping a temporary
        table while at 1023 transactions will cause assert) from 5.1 to
        branches/5.1. Separate action for return value DB_TOO_MANY_CONCURRENT_TRXS
        from that of DB_MUST_GET_MORE_FILE_SPACE in row_drop_table_for_mysql().
        
        
        ------------------------------------------------------------------------
      7c6ba7b4
  22. 02 Jul, 2010 3 commits