1. 14 May, 2011 1 commit
  2. 13 May, 2011 1 commit
  3. 12 May, 2011 3 commits
  4. 10 May, 2011 2 commits
  5. 09 May, 2011 1 commit
    • Serge Kozlov's avatar
      WL#5867 · e8b54a7c
      Serge Kozlov authored
      Replaced the error code by error name
      e8b54a7c
  6. 06 May, 2011 2 commits
  7. 05 May, 2011 4 commits
    • Luis Soares's avatar
      BUG#12354268 · 8cc75b2d
      Luis Soares authored
      Automerged bzr bundle from bug report:
      luis.soares@oracle.com-20110505224815-6ob90n7suxsoizvs.bundle
      8cc75b2d
    • Luis Soares's avatar
      BUG#11762616: BUG#55229: 'POSTION' · ed6aae83
      Luis Soares authored
                  
      Fix for all "postion" in Oracle files (s/postion/position). 
      Updated the copyright notices where needed.
      ed6aae83
    • Luis Soares's avatar
      BUG#12354268: MYSQLBINLOG --BASE64-OUTPUT=DECODE-ROWS DOES NOT · e367a789
      Luis Soares authored
      WORK WITH --START-POSITION
            
      If setting --start-position to start after the FD event, mysqlbinlog
      will output an error stating that it has not found an FD event.
      However, its not that mysqlbinlog does not find it but rather that it
      does not processes it in the regular way (i.e., it does not print it).
      Given that one is using --base64-output=DECODE-ROWS then not printing
      it is actually fine.
            
      To fix this, we make mysqlbinlog not to complain when it has not
      printed the FD event, is outputing in base64, but is decoding the
      rows.
      e367a789
    • Tatiana Azundris Nurnberg's avatar
  8. 04 May, 2011 1 commit
    • Alexander Nozdrin's avatar
      Patch for Bug#12394306: the sever may crash if mysql.event is corrupted. · ca6e7781
      Alexander Nozdrin authored
      The problem was that wrong structure of mysql.event was not detected and
      the server continued to use wrongly-structured data.
      
      The fix is to check the structure of mysql.event after opening before
      any use. That makes operations with events more strict -- some operations
      that might work before throw errors now. That seems to be Ok.
      
      Another side-effect of the patch is that if mysql.event is corrupted,
      unrelated DROP DATABASE statements issue an SQL warning about inability
      to open mysql.event table. 
      ca6e7781
  9. 03 May, 2011 2 commits
  10. 02 May, 2011 1 commit
  11. 29 Apr, 2011 5 commits
  12. 27 Apr, 2011 3 commits
  13. 26 Apr, 2011 3 commits
  14. 25 Apr, 2011 1 commit
  15. 23 Apr, 2011 1 commit
  16. 22 Apr, 2011 1 commit
    • Sergey Glukhov's avatar
      Bug#11756928 48916: SERVER INCORRECTLY PROCESSING HAVING CLAUSES WITH AN ORDER BY CLAUSE · 76f37a02
      Sergey Glukhov authored
      Before sorting HAVING condition is split into two parts,
      first part is a table related condition and the rest of is
      HAVING part. Extraction of HAVING part does not take into account
      the fact that some of conditions might be non-const but
      have 'used_tables' == 0 (independent subqueries)
      and because of that these conditions are cut off by
      make_cond_for_table() function.
      The fix is to use (table_map) 0 instead of used_tables in
      third argument for make_cond_for_table() function.
      It allows to extract elements which belong to sorted
      table and in addition elements which are independend
      subqueries.
      76f37a02
  17. 21 Apr, 2011 1 commit
  18. 20 Apr, 2011 6 commits
  19. 18 Apr, 2011 1 commit