1. 09 Nov, 2012 1 commit
  2. 08 Nov, 2012 3 commits
  3. 07 Nov, 2012 1 commit
  4. 06 Nov, 2012 1 commit
  5. 02 Nov, 2012 1 commit
  6. 01 Nov, 2012 3 commits
  7. 31 Oct, 2012 4 commits
  8. 09 Oct, 2012 1 commit
  9. 14 Oct, 2012 1 commit
  10. 02 Oct, 2012 1 commit
  11. 27 Sep, 2012 2 commits
  12. 26 Sep, 2012 3 commits
  13. 25 Sep, 2012 1 commit
  14. 26 Sep, 2012 1 commit
  15. 24 Sep, 2012 2 commits
  16. 14 Sep, 2012 1 commit
    • unknown's avatar
      Fix bug lp:1009187, mdev-373, mysql bug#58628 · f89d6a6f
      unknown authored
      Analysis:
      The queries in question use the [unique | index]_subquery execution methods.
      These methods reuse the ref keys constructed by create_ref_for_key(). The
      way create_ref_for_key() works is that it doesn't store in ref.key_copy[]
      store_key elements that represent constants. In particular it doesn't store
      the store_key for NULL constants.
      
      The execution of [unique | index]_subquery calls
      subselect_uniquesubquery_engine::copy_ref_key, which in addition to copy
      the left IN argument into a index lookup key, is supposed to detect if
      the left IN argument contains NULLs. Since the store_key for the NULL
      constant is not copied into the key array, the null is not detected, and
      execution erroneously proceeds as if it should look for a complete match.
      
      Solution:
      The solution (unlike MySQL) is to reuse already computed information about
      NULL presence. Item_in_optimizer::val_int already finds out if the left IN
      operand contains NULLs. The fix propagates this to the execution methods
      subselect_[unique | index]subquery_engine::exec so it knows if there were
      NULL values independent of the presence of keys.
      
      In addition the patch siplifies copy_ref_key() and the logic that hanldes
      the case of NULLs in the left IN operand.
      f89d6a6f
  17. 11 Sep, 2012 1 commit
  18. 05 Sep, 2012 1 commit
  19. 03 Sep, 2012 1 commit
  20. 31 Aug, 2012 2 commits
    • Annamalai Gurusami's avatar
      Bug #13453036 ERROR CODE 1118: ROW SIZE TOO LARGE - EVEN · e5817934
      Annamalai Gurusami authored
      THOUGH IT IS NOT.
      
      The following error message is misleading because it claims 
      that the BLOB space is not counted.  
      
      "ERROR 1118 (42000): Row size too large. The maximum row size for 
      the used table type, not counting BLOBs, is 8126. You have to 
      change some columns to TEXT or BLOBs"
      
      When the ROW_FORMAT=compact or ROW_FORMAT=REDUNDANT is used,
      the BLOB prefix is stored inline along with the row.  So 
      the above error message is changed as follows depending on
      the row format used:
      
      For ROW_FORMAT=COMPRESSED or ROW_FORMAT=DYNAMIC, the error
      message is as follows:
      
      "ERROR 42000: Row size too large (> 8126). Changing some
      columns to TEXT or BLOB may help. In current row format, 
      BLOB prefix of 0 bytes is stored inline."
      
      For ROW_FORMAT=COMPACT or ROW_FORMAT=REDUNDANT, the error
      message is as follows:
      
      "ERROR 42000: Row size too large (> 8126). Changing some
      columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or 
      ROW_FORMAT=COMPRESSED may help. In current row
      format, BLOB prefix of 768 bytes is stored inline."
      
      rb://1252 approved by Marko Makela
      e5817934
    • unknown's avatar
      No commit message · 237b124b
      unknown authored
      No commit message
      237b124b
  21. 30 Aug, 2012 2 commits
    • Marko Mäkelä's avatar
      Bug#14554000 CRASH IN PAGE_REC_GET_NTH_CONST(NTH=0) DURING COMPRESSED · d608e1ab
      Marko Mäkelä authored
      PAGE SPLIT
      
      page_rec_get_nth_const(): Map nth==0 to the page infimum.
      
      btr_compress(adjust=TRUE): Add a debug assertion for nth>0. The cursor
      should never be positioned on the page infimum.
      
      btr_index_page_validate(): Add test instrumentation for checking the
      return values of page_rec_get_nth_const() during CHECK TABLE, and for
      checking that the page directory slot 0 always contains only one
      record, the predefined page infimum record.
      
      page_cur_delete_rec(), page_delete_rec_list_end(): Add debug
      assertions guarding against accessing the page slot 0.
      
      page_copy_rec_list_start(): Clarify a comment about ret_pos==0.
      
      rb:1248 approved by Jimmy Yang
      d608e1ab
    • Marko Mäkelä's avatar
      Bug#14547952: DEBUG BUILD FAILS ASSERTION IN RECORDS_IN_RANGE() · e8a59559
      Marko Mäkelä authored
      ha_innodb::records_in_range(): Remove a debug assertion
      that prohibits an open range (full table).
      
      The patch by Jorgen Loland only removed the assertion from the
      built-in InnoDB, not from the InnoDB Plugin.
      e8a59559
  22. 28 Aug, 2012 1 commit
  23. 24 Aug, 2012 5 commits