1. 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
  2. 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
  3. 08 Dec, 2010 1 commit
  4. 03 Dec, 2010 1 commit
  5. 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
  6. 23 Nov, 2010 1 commit
  7. 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
  8. 08 Nov, 2010 2 commits
  9. 29 Oct, 2010 1 commit
  10. 05 Oct, 2010 4 commits
  11. 20 Aug, 2010 2 commits
  12. 10 Aug, 2010 1 commit
  13. 02 Aug, 2010 2 commits
  14. 30 Jul, 2010 1 commit
  15. 21 Jul, 2010 2 commits
  16. 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
  17. 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
  18. 02 Jul, 2010 3 commits
  19. 28 Jun, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#54041: MySQL 5.0.92 fails when tests from Connector/C suite run · 07767edc
      Davi Arnaut authored
      The problem was that a user could supply supply data in chunks
      via the COM_STMT_SEND_LONG_DATA command to prepared statement
      parameter other than of type TEXT or BLOB. This posed a problem
      since other parameter types aren't setup to handle long data,
      which would lead to a crash when attempting to use the supplied
      data.
      
      Given that long data can be supplied at any stage of a prepared
      statement, coupled with the fact that the type of a parameter
      marker might change between consecutive executions, the solution
      is to validate at execution time each parameter marker for which
      a data stream was provided. If the parameter type is not TEXT or
      BLOB (that is, if the type is not able to handle a data stream),
      a error is returned.
      07767edc
  20. 21 Jun, 2010 2 commits
  21. 17 Jun, 2010 1 commit
    • Joerg Bruehe's avatar
      Bug#54590 "make_binary_distribution" fails because a command · d4c4bd6e
      Joerg Bruehe authored
                 line exceeds the limit
      
      The number and/or names of our files for the main test suite
      (contents of "mysql-test/t/") now exceeds the command line
      length limit on AIX.
      Solve the problem by using separate "cp" commands for the
      various file name extensions.
      d4c4bd6e
  22. 15 Jun, 2010 1 commit
  23. 14 Jun, 2010 1 commit
  24. 10 Jun, 2010 1 commit