1. 18 Apr, 2012 1 commit
  2. 16 Apr, 2012 5 commits
  3. 06 Apr, 2012 2 commits
  4. 05 Apr, 2012 2 commits
  5. 04 Apr, 2012 4 commits
  6. 03 Apr, 2012 2 commits
    • Michael Widenius's avatar
      Merge with 5.1 · 24a67aa8
      Michael Widenius authored
      24a67aa8
    • Michael Widenius's avatar
      Fixed lp:970528 "Server crashes in my_strnncollsp_simple on LEFT JOIN with CSV table, TEXT field" · a3bee835
      Michael Widenius authored
      The main problem was a bug in CSV where it provided wrong statistics (it claimed the table was empty when it wasn't)
      I also fixed wrong freeing of blob's in the CSV handler. (Any call to handler::read_first_row() on a CSV table with blobs would fail)
      
      
      
      mysql-test/r/csv.result:
        Added new test case
      mysql-test/r/partition_innodb.result:
        Updated test results after fixing bug with impossible partitions and const tables
      mysql-test/t/csv.test:
        Added new test case
      sql/sql_select.cc:
        Cleaned up code for handling of partitions.
        Fixed also a bug where we didn't threat a table with impossible partitions as a const table.
      storage/csv/ha_tina.cc:
        Allocate blobroot onces.
      a3bee835
  7. 02 Apr, 2012 1 commit
  8. 30 Mar, 2012 4 commits
  9. 29 Mar, 2012 3 commits
  10. 28 Mar, 2012 2 commits
    • Michael Widenius's avatar
      Merge with 5.1 · 3bc932ec
      Michael Widenius authored
      3bc932ec
    • Michael Widenius's avatar
      Fixed lp:944422 "mysql_upgrade destroys Maria tables?" · 74b06493
      Michael Widenius authored
      The issue was that check/optimize/anaylze did not zerofill the table before they started to work on it.
      Added one more element to not often used function handler::auto_repair() to allow handler to decide when to auto repair.
      
      
      mysql-test/suite/maria/r/maria-autozerofill.result:
        Test case for lp:944422
      mysql-test/suite/maria/t/maria-autozerofill.test:
        Test case for lp:944422
      sql/ha_partition.cc:
        Added argument to auto_repair()
      sql/ha_partition.h:
        Added argument to auto_repair()
      sql/handler.h:
        Added argument to auto_repair()
      sql/table.cc:
        Let auto_repair() decide which errors to trigger auto-repair
      storage/archive/ha_archive.h:
        Added argument to auto_repair()
      storage/csv/ha_tina.h:
        Added argument to auto_repair()
      storage/maria/ha_maria.cc:
        Give better error & warning messages for auto-repaired tables.
      storage/maria/ha_maria.h:
        Added argument to auto_repair()
        Always auto-repair in case of moved table.
      storage/maria/ma_open.c:
        Remove special handling of HA_ERR_OLD_FILE (this is now handled in auto_repair())
      storage/myisam/ha_myisam.h:
        Added argument to auto_repair()
      74b06493
  11. 21 Mar, 2012 2 commits
  12. 15 Mar, 2012 1 commit
  13. 14 Mar, 2012 2 commits
  14. 12 Mar, 2012 3 commits
  15. 09 Mar, 2012 4 commits
    • Igor Babaev's avatar
      Fixed LP bug #930814. · 8c083498
      Igor Babaev authored
      This bug was introduced into mariadb 5.2 in the December 2010 with
      the patch that added a new engine property: the ability to support
      virtual columns.    
      As a result of this bug the information from frm files for tables 
      that contained virtual columns did not appear in the information schema
      tables.
      8c083498
    • Michael Widenius's avatar
      Added test case for lp:905782 "Assertion `pageno < ((1ULL) << 40)' failed at... · 028523e9
      Michael Widenius authored
      Added test case for lp:905782 "Assertion `pageno < ((1ULL) << 40)' failed at ma_pagecache.c:3438: pagecache_read or table corruption on INSERT into a ucs2 table"
      The orignal bug has been fixed earlier
      028523e9
    • unknown's avatar
      ea736c93
    • Igor Babaev's avatar
      Fixed LP bug #884175. · af7213d5
      Igor Babaev authored
      If in the where clause of the a query some comparison conditions on the
      field under a MIN/MAX aggregate function contained constants whose sizes
      exceeded the size of the field then the query could return a wrong result
      when the optimizer had chosen to apply the MIN/MAX optimization.
      With such conditions the MIN/MAX optimization still could be applied, yet
      it would require a more thorough analysis of the keys built to find
      the value of MIN/MAX aggregate functions with index look-ups.   
      The current patch just prohibits using the MIN/MAX optimization in this
      situation.
      af7213d5
  16. 06 Mar, 2012 2 commits